Find first event where state went wrong.
AllSource keeps accepted state changes as ordered events. Inspect timeline, compare state across timestamps, preview replay impact, then rebuild one tenant projection without rewriting source history.
- 10:01:04checkout.startedstate valid
- 10:01:12payment.authorizedfirst diff
- 10:01:15inventory.rejecteddownstream
Direct answer
What is event replay debugging?
Event replay debugging uses the durable sequence of domain events to reconstruct how state changed. Instead of starting with an incorrect current row and guessing, an engineer reads events in order, derives state at selected boundaries, and identifies the first transition where the actual result diverges from the expected result.
Projection replay is a narrower operation. It runs existing source events through read-model logic again. This can rebuild a projection after a code correction, add historical data to a new view, or validate a changed interpretation. It should not mutate accepted source events. Incorrect facts require explicit correction or compensating events, not silent history edits.
Investigation workflow
Move from symptom to bounded replay.
Do not start by replaying everything. Bound the evidence, inspect impact, then rebuild one disposable view.
- 01
Find one broken outcome
Start with entity, projection, tenant, or time window. Avoid replaying everything before you can state which derived result is wrong.
- 02
Read ordered source events
Inspect event type, entity, timestamp, version, and metadata in sequence. Current state alone cannot show which transition introduced divergence.
- 03
Compare state across time
Reconstruct state before and after suspected event. This narrows investigation to first point where expected and actual state differ.
- 04
Analyze replay impact
Preview event count, date range, event-type distribution, sampled entities, readiness checks, and warnings without changing source or projection state.
- 05
Rebuild projection
Replay tenant-scoped events through corrected projection logic. Existing read model remains live until full rebuild succeeds and atomic replacement is ready.
- 06
Record result
Keep replay identifier, target, processed and failed counts, completion status, and resulting validation beside incident or migration evidence.
Concrete replay contract
What does replay analysis return?
TypeScript and Rust SDKs expose the same tenant-scoped analysis fields before a replay starts. Those fields turn “rebuild it” into a reviewable decision with a bounded source range, affected entities, server checks, warnings, and run evidence.
- Scope
- total_events · sampled_events · analysis_scope
- Whether review covers full tenant history or a sample.
- Time range
- first_event_at · last_event_at
- Whether source window matches incident or migration boundary.
- Affected data
- event_type_distribution · sampled_entities
- Which event types and entities deserve validation before rebuild.
- Readiness
- checks · warnings · ready_to_replay
- Whether server-side invariants permit replay to start.
- Run evidence
- processed_events · failed_events · events_per_second
- Whether completed run processed expected scope without hidden failures.
Know which replay you mean
Four operations, different risks.
Event stores support history and derived-state reconstruction. They do not automatically capture every nondeterministic input needed to re-execute application or LLM behaviour exactly.
Read event-store architecture- Timeline inspection
- Read accepted events in order to explain what happened. No derived state changes.
- Point-in-time reconstruction
- Fold events through a chosen timestamp to inspect what application state should have been then.
- Projection replay
- Rebuild disposable read model from durable source events, commonly after projection logic or schema interpretation changes.
- Execution replay
- Re-run application or agent behaviour. External calls, model responses, time, randomness, and side effects require separate capture or stubbing.
Analyze before starting replay.
Query Service keeps replay tenant-scoped. Analysis returns event volume, sample coverage, affected event types and entities, readiness checks, and warnings without modifying source or projection state.
Start only after checks pass. Follow replay identifier for status and progress. Cancel running rebuild if assumptions change; successful replacement remains separate from immutable event history.
import { AllSourceClient } from "@allsourcedev/client";
const client = new AllSourceClient({
baseUrl: process.env.ALLSOURCE_URL!,
apiKey: process.env.ALLSOURCE_API_KEY!,
});
const analysis = await client.analyzeProjectionReplay("event-count");
if (analysis.ready_to_replay && analysis.total_events > 0) {
const run = await client.startProjectionReplay(analysis.projection_name);
const progress = await client.getProjectionReplay(run.replay_id);
console.log(progress.status, progress.progress_percentage);
}Safe operating boundary
Source survives failed rebuild.
AllSource Core remains the durable source of truth through WAL and Parquet. Query Service owns tenant-facing projection compute and replay jobs. Projection state is rebuildable; event history is not swapped or deleted by projection replay.
Replay Studio requires impact analysis before starting atomic rebuild. Current read model stays live during build. Failed or cancelled run does not replace it. This protects availability, but the application team still must validate projector determinism, schema compatibility, and expected result.
What to verify after replay
- Processed event count matches analyzed scope.
- Failed event count is zero or explicitly understood.
- Known entities match expected state at selected boundaries.
- New projection answers realtime, HTTP, and analytics reads as designed.
- Incident record links replay run and validation evidence, never raw secrets.
Primary references
Verify the model and SDK contract.
Debug from history, not guesswork.
Start hosted trial, inspect API and SDK workflow, or self-host Apache-2.0 Core. Replay features matter when source history, projection rebuilds, and point-in-time evidence are part of normal product operation—not when current state alone is enough.