Task: Test the down-window delivery
Table of Contents
This page documents a task in the Streams are not provisioned for the subjects services durabl… story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
(Describe what user-visible-or-internal change this task produces.)
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Streams are not provisioned for the subjects services durabl… |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-10-18 |
3. Acceptance
4. Plan
(Implementation strategy. Written when work starts; key decisions
are distilled into the parent story's * Decisions at close, but the
plan itself stays — it is the historical record of what we did.)
5. Measurements
Every number this task claims about a tree, with the command that produced it
and the commit it was measured at. A number without both is not a measurement,
because a clean-up record describes a tree and trunk moves under a branch: a
consumer count, a gate's component count and a suite's size all change with no
code changing, and the reader of a bare number cannot tell which tree it came
from. Where the raw output matters, put it in an evidence/ file beside the
task and name that file in the Command column.
| What | Value | Command | Commit |
|---|---|---|---|
6. Notes
7. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario)
that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Result
The down-window delivery is covered by a test that needs no service restart. It creates a consumer through the production path, leaves the subscription to drain as a shutdown would, and asserts against the server that the consumer still exists with its creation time unchanged. A command published with no subscriber is then retained and shows as unprocessed on that consumer, and re-subscribing delivers and acks it, with the queue drained and nothing redelivered.
The creation time is the assertion that matters: it proves the consumer was reused rather than recreated, which is the whole property.
A negative case pins the old behaviour. A raw subscribe that creates its own durable consumer, the exact call the helper used to make, has its consumer removed by the server on drain. That is the control which shows the survival assertion discriminates between the old behaviour and the new.
Proven rather than assumed: with the production helper temporarily reverted to implicit creation, the test fails with "the consumer did not survive the drain". The revert was undone and the tree matches the commit.
Two production seams were added to observe the server rather than the client, since the client had no way to assert server side consumer state. Two pre-existing cases that broke the environment for later tests in the same binary, by unsetting NATS variables instead of restoring them, were fixed with a guard.