Verify tiered event-store existence and write-routing behavior #609

Problem

TieredEventStore has no recorded line coverage in the October 5, 2026 .NET 10 coverage run. Its public behavior needs tests independent of the existing TieredEventReader tests. You can view a test coverage report I generated here: index.html

There is also a potential correctness bug: StreamExists returns hotExists && archiveExists. A stream present in only one tier is therefore reported as missing, even though the tiered reader can read from that tier. This is a code-review finding; add a reproducing test and confirm the intended contract before changing the implementation.

Source: TieredEventStore.cs.

Proposed tests

• Exercise stream existence when the stream is present in hot storage only, archive storage only, both stores, or neither store.
• Read through the tiered store's public forward and backward APIs, including a stream spanning both tiers. Assert event order, requested counts, and absence of duplicates.
• Append through both the single-stream and batch APIs. Verify that events reach hot storage and do not alter the archive.
• Truncate and delete through the tiered store. Verify that these operations affect only hot storage.
• Establish the existence-check contract when the archive implements only IEventReader, which does not expose StreamExists.

Acceptance criteria

• Tests reproduce the current behavior for streams present in only one tier.
• The intended existence contract is documented in the tests; any confirmed bug is fixed with a regression test.
• Reads, appends, truncation, and deletion are tested through the public tiered-store API with assertions on stored events.
• Archive-only readers are handled according to an explicit contract.
• Tests use isolated in-memory stores or controlled store implementations and do not require Docker.

Validation

Run the affected persistence/application test project and collect focused coverage for TieredEventStore. Use behavioral assertions as the completion criterion, not a percentage target. A full provider-suite rerun is not required for this isolated work.