Skip to content

refactor(mapper): add ResultToGraphChunks convenience for the map+split flow#243

Open
xytan0056 wants to merge 1 commit into
mainfrom
refactor/mapper-result-to-graph-chunks
Open

refactor(mapper): add ResultToGraphChunks convenience for the map+split flow#243
xytan0056 wants to merge 1 commit into
mainfrom
refactor/mapper-result-to-graph-chunks

Conversation

@xytan0056

Copy link
Copy Markdown
Contributor

What

Adds mapper.ResultToGraphChunks(ctx, result, maxBytes) — a single public entry point that turns a targethasher.Result into the ordered []entity.GetTargetGraphResponse chunks that storage.WriteGraphStream consumes.

Why

The ResultToTargetGraphstreaming.SplitBySizestreaming.SplitMetadata → assemble recipe was hand-copied identically in orchestrator/native_orchestrator.go and example/cmd/query-bench/main.go. Worse, off-module callers cannot reproduce it at all: streaming.SplitBySize / SplitMetadata live under internal/, so a CI-integrated Orchestrator implementation in a downstream repo has no supported way to serialize a computed graph for caching.

This effectively reinstates the ergonomics of the old common.ResultToGetTargetGraphResponse (removed in the proto→JSON refactor, #222) — but at the entity layer, byte-size based, and without leaking the internal split helpers into the public API.

Design

  • streaming.SplitBySize / SplitMetadata stay internal/ — they're wire-format implementation details.
  • The two-step ResultToTargetGraph API is unchanged, for callers that need to control or interleave chunking.
  • ResultToGraphChunks is the convenience path for the common "map, split, hand to WriteGraphStream" flow.

Changes

  • New mapper.ResultToGraphChunks + tests (single-chunk, tiny-budget split, context cancellation).
  • Collapse the two existing callsites onto it (net −40 LOC).

Test plan

  • make build, make test (23/23 pass), make gazelle clean.

…it flow

Reintroduce a single public entry point that turns a targethasher.Result
into the ordered []entity.GetTargetGraphResponse chunks that
storage.WriteGraphStream consumes. The map -> SplitBySize -> SplitMetadata
recipe was hand-assembled identically in nativeOrchestrator and query-bench,
and off-module callers (e.g. CI-integrated orchestrators) could not reproduce
it at all because streaming.SplitBySize / SplitMetadata live under internal/.

ResultToGraphChunks keeps the split helpers internal while exposing the common
"map, split, hand to WriteGraphStream" path. The two-step ResultToTargetGraph
API stays for callers that need to control chunking. Both existing callsites
collapse onto the new function (net -40 LOC).
@xytan0056
xytan0056 requested review from a team as code owners July 25, 2026 07:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant