README
¶
changeset
changeset resolves batch identity into the changes a batch contains. Current consumers include build-runner and scorer implementations and the path-overlap conflict analyzer. The land controller loads member requests directly because its Runway payload preserves one ordered merge step per request.
Why it exists
A Batch is a thin reference entity: it carries the IDs of the requests it contains, not their changes. Decision and action extensions such as scorers, build runners, and conflict analyzers are handed that identity and resolve the granular content themselves through an injected Resolver, rather than depending on a controller to pre-resolve and pass the data in. The resolver uses the queue-scoped storage aggregate to reach the request store (to walk a batch's contained requests) and the change store (to attach provider details).
Two fidelities
Both methods operate on one batch per call:
- The raw view returns a batch's contained changes as URIs only, in request order. It performs no change-store read. Build-runner implementations use it to construct base and head inputs.
- The detailed view returns a single batch's normalized, batch-level changes: one entry per claimed URI, each carrying the provider details recorded in the change store, aggregated across every request in the batch. Because the change store returns rows for every request that ever claimed a URI, the resolver selects the row owned by the requesting request. Scorers and detail-aware conflict analyzers use this view.
Testing
A programmable in-memory fake lives in fake/: seed per-batch results and inject errors without a real store. A generated mock lives in mock/ for tests that assert on exact call expectations. Extensions that take a Resolver can be exercised against either.
Documentation
¶
Overview ¶
Package changeset resolves batch identity into the changes a batch contains. It is the single place the orchestrator walks batch -> requests -> changes, consolidating controller-side and backend-specific traversal. Decision/action extensions (scorer, buildrunner, and future detail-aware conflict analyzers) take thin identity entities and resolve their granular content through an injected Resolver instead of being handed pre-resolved data by a controller.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Resolve ¶
Resolve binds Stores to one queue. The wiring layer supplies it, because that is the layer that knows which service's aggregate serves a queue.
type Resolver ¶
type Resolver interface {
// ChangesForBatch resolves a batch's contained requests into their raw
// changes (URIs only; no change-store read), in batch.Contains order. A batch
// with no requests yields an empty slice. Used by build runners for their
// base and head batches.
ChangesForBatch(ctx context.Context, batch entity.Batch) ([]change.Change, error)
// DetailedForBatch resolves a batch into its normalized, batch-level view:
// one entity.ChangeInfo per claimed URI (URI plus the provider details read
// from the change store), aggregated across every request in the batch. For
// each URI it selects the record owned by the request, since the change store
// returns rows for all requests that ever claimed the URI. Used by the scorer
// and detail-aware analyzers.
DetailedForBatch(ctx context.Context, batch entity.Batch) (entity.BatchChanges, error)
}
Resolver turns batch identity into the changes the batch contains. Both methods operate on a single batch — callers with several batches loop and keep the per-batch boundary by holding a slice per batch. The two methods differ only in fidelity: ChangesForBatch is the cheap URI-only view; DetailedForBatch reads the change store for provider details.
type Stores ¶
type Stores interface {
// GetRequestStore returns the queue's RequestStore.
GetRequestStore() storage.RequestStore
// GetChangeStore returns the queue's ChangeStore.
GetChangeStore() storage.ChangeStore
}
Stores is the slice of a queue-scoped storage aggregate this package needs. Declaring it here rather than naming a service's aggregate keeps `core/` free of any dependency on a service package; every aggregate that exposes these two accessors satisfies it.
Source Files
Directories