GH-4059: say so when a publish rule overwrites a listener's EndpointMode

[jeremydmiller]

Closes #4059.

What was wrong

EndpointMode is one property governing both directions, so on any transport where publishing and listening resolve to the same Endpoint object — a RabbitMQ queue, a Redis stream, a Pulsar topic — this silently discards the listener's mode:

opts.ListenToRabbitQueue("orders")
    .ProcessInParallelWithNativeAcks()
    .PartitionProcessingByGroupId(PartitionSlots.Five);

opts.PublishMessage<Order>()
    .ToRabbitQueue("orders")
    .SendInline();                          // resets Mode to Inline, no warning

Two people hit it independently within an hour while building the Redis Streams and Pulsar transports.

The collision is now reported

Endpoint records ListenerRequestedMode and SubscriberRequestedMode alongside the outcome, so ListenerConfigurationValidator can see both requests and say which mode each side asked for, which one actually won, and that the answer depends on the order Wolverine applies the two configuration blocks.

That recording is the whole reason the check can work. Both sides are delayed configuration, so a guard in the Mode setter catches one ordering and misses the reverse — the same reasoning as GH-3712's parallelism clamp, and the placement the issue asked for. A test runs both orderings for exactly that reason.

Applies to UseDurableOutbox() and BufferedInMemory() too; SendInline() is the loudest instance, not the only one.

Warning rather than refusal — a judgement call worth reviewing

The issue offered "warn or throw". I went with warn, and the reasoning is the part to check:

"Send inline, receive durably" is a coherent thing to want. With a single Mode property Wolverine cannot express it, so throwing would refuse a configuration that is meaningful rather than mistaken, leaving no remedy but to give one of the two calls up. Option 2 in the issue — a distinct SendingMode — removes the collision at the root and needs its own migration story; that is where the refusal belongs.

The Fatal that already existed now blames the right call

This is the half with teeth, and it closes the gap the issue names: GH-3712's validator "sees the endpoint after the overwrite and cannot tell 'the user asked for Inline' from 'the user's listener mode was clobbered by a publish rule'."

Before, that case refused the host with:

use ProcessInParallelWithNativeAcks() instead of ProcessInline()

— advice pointing at a ProcessInline() call the reader never wrote, and in the report's own configuration, telling them to make a change their listener had already made.

It now names SendInline() and the publishing side when that is what imposed Inline, and a test asserts the message does not say "instead of ProcessInline()" in that case. When the listener genuinely asked for Inline, the original advice is unchanged — also asserted.

Tests

Nine, covering:

• both orderings of the two configuration blocks
• UseDurableOutbox() over an Inline listener, so the check is not SendInline()-specific
• the three cases that must stay quiet: sides that agree, a side that named no mode at all (a bare PublishAllMessages().To(...) — the common case, and why this is not merely "Mode was assigned twice"), and a listen-only endpoint
• both halves of the partitioning message

The report's literal ProcessInParallelWithNativeAcks() combination is built directly against a native-ack-capable stub endpoint, because supportsNativeAck is opt-in per transport and the plain stub throws on that mode — the durable inbox stands in for the fluent-API version of the same case.

Verification

CoreTests 3047 green. Pinned full-solution build clean: dotnet build wolverine.slnx -c Release -f net9.0.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VDUrBeB4tTnKj4AExCS1nj