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.

Emacs 29.3 (Org mode 9.6.15)