Area: ingest · mq. Test gap, found in @EricAndrechek's review of #585. taitelee agreed in-thread to do it as a follow-up.
Expected: a test fails if the undo after a failed DLQ resize goes back to using the resize's own context. The bug #585 fixed: the DLQ update most likely fails because it used up the shared resizeTimeout. An undo on that same expired context returns context deadline exceeded and never touches the stream. The fix gives the undo its own rollbackTimeout, rooted in the caller's context (internal/mq/embedded.go:69-74,212-221; #586 moved this code into SetMaxBytes).
Actual: TestEmbeddedNATS_SetMaxBytes_DLQFailureRollsBackIngest (internal/mq/embedded_test.go:331) makes the DLQ update fail with a retention-policy conflict. JetStream refuses it immediately, with about 10s still left on the resize context. The undo succeeds, and it would succeed the same way on the pre-fix code, because the resize context never expires in this scenario. The test shows the undo branch runs. It doesn't test the budget.
Impact: a regression would go unnoticed. If a DLQ resize stalls, the ingest stream stays at the new cap and the DLQ at the old one until a later reload applies both again. The error says so, and MaxBytes keeps reporting the previous budget.
Scope: the test needs a DLQ failure that uses up the resize budget, not an immediate refusal. The in-thread suggestion was a seam in internal/app. That code now lives in internal/mq since #586.
Related: #585 (thread on internal/app/app_test.go:215), #586
From @EricAndrechek's #585 review. taitelee agreed to it as a follow-up, and nobody filed it before merge (pm-triage all routine). Validated by code-read against 990f713f on 2026-09-18.
Area: ingest · mq. Test gap, found in @EricAndrechek's review of #585. taitelee agreed in-thread to do it as a follow-up.
Expected: a test fails if the undo after a failed DLQ resize goes back to using the resize's own context. The bug #585 fixed: the DLQ update most likely fails because it used up the shared
resizeTimeout. An undo on that same expired context returnscontext deadline exceededand never touches the stream. The fix gives the undo its ownrollbackTimeout, rooted in the caller's context (internal/mq/embedded.go:69-74,212-221; #586 moved this code intoSetMaxBytes).Actual:
TestEmbeddedNATS_SetMaxBytes_DLQFailureRollsBackIngest(internal/mq/embedded_test.go:331) makes the DLQ update fail with a retention-policy conflict. JetStream refuses it immediately, with about 10s still left on the resize context. The undo succeeds, and it would succeed the same way on the pre-fix code, because the resize context never expires in this scenario. The test shows the undo branch runs. It doesn't test the budget.Impact: a regression would go unnoticed. If a DLQ resize stalls, the ingest stream stays at the new cap and the DLQ at the old one until a later reload applies both again. The error says so, and
MaxByteskeeps reporting the previous budget.Scope: the test needs a DLQ failure that uses up the resize budget, not an immediate refusal. The in-thread suggestion was a seam in
internal/app. That code now lives ininternal/mqsince #586.Related: #585 (thread on
internal/app/app_test.go:215), #586From @EricAndrechek's #585 review. taitelee agreed to it as a follow-up, and nobody filed it before merge (pm-triage
allroutine). Validated by code-read against990f713fon 2026-09-18.