chore: doc epoxy fanout behavior

[NathanFlurry]

Description

Please include a summary of the changes and the related issue. Please also include relevant motivation and context.

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[NathanFlurry]

• chore: doc epoxy fanout behavior #4613 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[railway-app]

🚅 Deployed to the rivet-pr-4613 environment in rivet-frontend

Service	Status	Web	Updated (UTC)
website	😴 Sleeping (View Logs)	Web	Apr 12, 2026 at 9:35 pm
frontend-inspector	❌ Build Failed (View Logs)	Web	Apr 12, 2026 at 9:27 pm
mcp-hub	✅ Success (View Logs)	Web	Apr 12, 2026 at 9:26 pm
frontend-cloud	❌ Build Failed (View Logs)	Web	Apr 12, 2026 at 9:25 pm
kitchen-sink	❌ Build Failed (View Logs)	Web	Apr 12, 2026 at 9:25 pm
ladle	❌ Build Failed (View Logs)	Web	Apr 12, 2026 at 9:25 pm

[NathanFlurry]

Merge activity

• Apr 12, 9:25 PM UTC: Graphite couldn't merge this PR because it failed for an unknown reason.

[claude]

PR Review: chore: doc epoxy fanout behavior

Summary

This is a documentation-only PR that adds a 9-line Rust doc comment (///) to fanout_to_replicas in engine/packages/epoxy/src/http_client.rs. No logic is changed. The comment documents the intentional best-effort, fault-tolerant semantics of the fanout function.

Accuracy

The doc comment correctly describes three key behavioral properties:

1. The function is best-effort: per-replica failures, timeouts, and errors are absorbed internally.
2. The return value reflects only successful responses; failures are logged and silently dropped.
3. Quorum enforcement is the caller's responsibility, not this function's.

This matches the implementation: the function catches both request errors and tokio::time::timeout timeouts, logs them with tracing::warn!, and continues collecting from remaining replicas.

Minor Suggestion

The comment states callers "get whatever successful responses arrived before the fanout quorum target was met or the pending requests were exhausted." This is accurate, but it might also be useful to note that all replica connections are initiated concurrently upfront via FuturesUnordered (not lazily), since that shapes the latency/connection-count tradeoff callers should understand. Not blocking.

Conventions

All CLAUDE.md conventions are satisfied:

• Comments are complete sentences with no em dashes
• No rivet.gg references
• No tracing or logging changes
• No dependency changes

Verdict

Clean, accurate documentation. Ready to merge.