Skip to documentation
Browse documentation Operations

Reference / Operations

Recover from durable evidence, not from assumptions.

Stargazer treats the raw archive and committed ledger checkpoint as the recovery boundary. Workers may restart, databases may be rebuilt, and serving projections may be replaced, but the system must never skip history or serve a projection whose coverage no longer matches its evidence store.

01 / Invariants

Conditions that stop the pipeline.

  • the database is permanently bound to one Stellar network ID;
  • committed ledgers form one contiguous range and agree on the hash chain;
  • parallel decoders may finish out of order, but commits remain in ledger order;
  • a failed decode or write cannot advance the committed checkpoint;
  • failed transactions never mutate materialized current state;
  • historical replay never enters the live notification outbox;
  • an unrecognized parser or schema version fails visibly instead of being guessed;
  • the read API rejects a serving projection with stale or incompatible coverage.

02 / Health model

Expose progress at every boundary.

SignalWhy it mattersStatus
Archive partition freshness and completionShows whether the local recovery surface is current and complete.Partially implemented in markers and logs
Indexed ledger start/end and contract transaction countStates the exact bounded coverage served by the demo.Implemented in /health
Last fetched, decoded, and committed ledgerSeparates source lag, parser lag, and database lag.Planned for live ingestion
Parser failures by module and versionPrevents silent coverage loss after a protocol upgrade.Planned
Serving generation and coverage matchStops stale rankings when the compact range advances.Implemented
Outbox age, retries, and channel delivery statusSeparates detection success from notification success.Planned

03 / Failure modes

Expected response by failure class.

Remote source unavailable

Keep the committed checkpoint, retry with bounded backoff, then select the documented fallback source.

Archive ledger missing

Stop before opening a commit that would create a sparse range. Resynchronize that partition and retry.

Hash conflict

Stop ingestion and raise an operator incident. Do not resolve conflicting history automatically.

Unsupported XDR or Wasm

Preserve the raw record and coverage failure; generic facts may continue only when the ledger itself remains safely decodable.

Serving snapshot stale

Keep exact compact relationships available, return rankings as unavailable, rebuild, validate, and atomically publish.

Delivery channel unavailable

Retain the committed outbox event, retry idempotently, and report channel failure without rolling back chain facts.

04 / Publication

Build beside production, then rename.

  1. Open historical evidence read-only. The finalizer cannot modify the compact database.
  2. Write a new generation. Progress checkpoints and shard files make a long aggregation resumable.
  3. Create query indexes last. Bulk aggregation stays sequential and avoids maintaining rankings row by row.
  4. Validate schema and coverage. Required metadata and exact index key ordering are part of the read contract.
  5. Atomically replace the active file. The read API detects the new generation on the next request without restarting.

05 / Backup priority

Back up what cannot be regenerated first.

AssetRegenerable?Priority
Protocol registry sources, parser versions, and configurationNo—not without reconstructing research decisionsHighest
Alert-control policy and future delivery stateNoHighest
Local raw archiveUsually, while the upstream object remains availableHigh due to recovery time and bandwidth
Compact evidence databaseYes, from raw archive plus exact code/config versionMedium
Serving snapshotYes, from the compact databaseLow