[Docs] Fix Defer examples

[iancooper]

The examples for defer need fixing to support the DeferMessageOnError attribute

[codescene-delta-analysis]

No application code in the PR — skipped Code Health checks.

See analysis details in CodeScene

Quality Gate Profile: Clean Code Collective
Install CodeScene MCP: safeguard and uplift AI-generated code. Catch issues early with our IDE extension and CLI tool.

[claude]

PR Review: [Docs] Fix Defer examples

This is a good cleanup. Replacing the manual DeferMessageAction throw + ConcurrentDictionary retry-tracking workaround with the declarative [DeferMessageOnErrorAsync] attribute is the right move now that the attribute exists. The handler code is noticeably simpler and the documentation is more accurate about how the feature actually works.

A few things worth looking at:

---

README expected output is inaccurate

Both READMEs show this expected output:

Received message #5: Hello # 5
  -> Simulating failure for message #5 (message will be requeued with delay)
Received message #5: Hello # 5
  -> Successfully processed message #5

The second line shows message #5 again, but _messageCount is a static counter that increments on every invocation (including retries). When the requeued message arrives, Interlocked.Increment runs again and the output will say something like message #6: Hello # 5 — the greeting text stays the same (it's payload data from the sender) but the local counter moves forward. The expected output should reflect that:

Received message #5: Hello # 5
  -> Simulating failure for message #5 (message will be requeued with delay)
Received message #6: Hello # 5
  -> Successfully processed message #6

---

Consider showing the delayMilliseconds parameter

[DeferMessageOnErrorAsync(step: 0)]

The key differentiator between [DeferMessageOnErrorAsync] and [DontAckOnErrorAsync] is the configurable delay before requeue. Using the default (delayMilliseconds: 0) is fine for compilation purposes, but a sample specifically demonstrating Defer behaviour would be more instructive with an explicit delay, e.g.:

[DeferMessageOnErrorAsync(step: 0, delayMilliseconds: 5000)]

The README currently says "The message pump requeues the message with the configured delay (from the subscription's RequeueDelay)" which is a bit ambiguous when the attribute itself also carries a delay parameter — it's worth clarifying whether the attribute delay and the subscription delay are additive, max-of-two, or one takes precedence.

---

Brighter.slnx change is unrelated to stated purpose

Removing the build restriction from Paramore.Brighter.Testing.Tests:

-    <Project Path="tests/Paramore.Brighter.Testing.Tests/Paramore.Brighter.Testing.Tests.csproj">
-      <Build Solution="Debug|*" Project="false" />
-    </Project>
+    <Project Path="tests/Paramore.Brighter.Testing.Tests/Paramore.Brighter.Testing.Tests.csproj" />

This re-enables the test project for all Debug solution builds, which is separate from fixing Defer examples. If intentional, a brief mention in the PR description would help reviewers understand the intent — the project may have been excluded for a reason.

---

Overall

The core change is correct and well-motivated. Switching from manual retry-tracking to the declarative attribute is exactly what these samples should show. The issues above are minor (documentation accuracy and one unrelated slnx change) but worth addressing before merge.