GH-4059: fix the conflicting sending/listening modes in the transport test suites (@tmorejon's work from #4506) - #4597
Merged
Conversation
… test suites Extracted from @tmorejon's #4506, which found these while building a validator for GH-4059 and is the original work here. The core fix landed separately as #4582 with a WARNING rather than a rejection -- "send inline, receive durably" is a coherent thing to want that a single Endpoint.Mode cannot express -- but these 27 files are real misconfigurations either way, and #4582's warning now reports every one of them. Most are a `.SendInline()` on a publish rule for an endpoint whose listener separately asked for UseDurableInbox() or ProcessInParallelWithNativeAcks(); whichever configuration block Wolverine applied last silently decided the mode for both directions. The Redis dead letter tests are the interesting ones, and the reason this is worth landing rather than leaving as noise: they were RELYING on the bug. Their listener needs Inline, because only an Inline listener takes RedisStreamListener.MoveToErrorsAsync -- a buffered one dead-letters through TryBuildDeadLetterSender instead -- and it was silently getting that from the SendInline() on the publishing side sharing Endpoint.Mode. They now say ProcessInline() outright. Verified: Wolverine.Redis.Tests DeadLetterQueueTests 6 green, which is where these fixes overlap the GH-4559 rewrite of disabled_dead_letter_queue_should_not_create_dead_letter_stream (#4579). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VDUrBeB4tTnKj4AExCS1nj
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is @tmorejon's work, from #4506, and the commit is authored by them.
Relates to #4059. It lands the 27 transport-test fixes from that PR, which are valuable independently of the warn-vs-reject question the core fix settled.
Background
@tmorejon opened #4506 on 2026-09-20 with a validator for #4059 that throws on a conflicting sending/listening mode. I later wrote #4582 without noticing #4506 existed — that is my mistake, and #4582 is the one that got merged. It warns instead, because a single
Endpoint.Modecannot express "send inline, receive durably", so rejecting refuses a configuration that is meaningful rather than mistaken.But that disagreement was only ever about the core 5 files. The other 27 in #4506 are real misconfigurations either way, and #4582's warning now reports every one of them. So they are extracted here rather than lost with the closed PR.
What these are
Mostly a
.SendInline()on a publish rule for an endpoint whose listener separately asked forUseDurableInbox()orProcessInParallelWithNativeAcks()— whichever configuration block Wolverine applied last silently decided the mode for both directions.The Redis dead letter tests are the ones worth reading, and the reason this is worth landing rather than dismissing as log noise: they were relying on the bug. Their listener needs Inline, because only an Inline listener takes
RedisStreamListener.MoveToErrorsAsync— a buffered one dead-letters throughTryBuildDeadLetterSenderinstead — and it was silently getting Inline from theSendInline()on the publishing side sharingEndpoint.Mode. They now sayProcessInline()outright, with a comment explaining why.That is a genuine latent trap: had anyone "cleaned up" that
SendInline(), those tests would have started failing for a reason nowhere near the change.Verification
Wolverine.Redis.TestsDeadLetterQueueTests6 green — that file is where these fixes overlap the Compliance tests assert Wolverine's configuration objects, not the broker's actual state #4559 rewrite ofdisabled_dead_letter_queue_should_not_create_dead_letter_stream(GH-4559: make the compliance tests ask the broker, not Wolverine's configuration objects #4579), so it is the one real interaction.dotnet build wolverine.slnx -c Release -f net9.0.The remaining transports are covered by their own CI lanes here.
Closes #4506 in substance; that PR is closed with a pointer to this one and to #4582.
🤖 Generated with Claude Code
https://claude.ai/code/session_01VDUrBeB4tTnKj4AExCS1nj