Relay: forward a later upstream's Object Properties on a merged Subgroup

[floatdrop]

Summary

When several upstreams feed one Subgroup (§9.3), each subscriber's downstream stream copies the first contributor's SUBGROUP_HEADER. If that header had PROPERTIES clear (§11.4.2), a later contributor's Object Properties were silently left out on write. That breaks §2.5: a relay "MUST forward the Property to downstream subscribers".

The fix is reopen on demand (the design you chose). The writer tracks whether its streams set PROPERTIES. When an Object with Properties meets a stream without the bit:

• Stream not opened yet: it opens with the bit set, and nothing is reset.
• Stream already open: it is reset and reopened with the bit set.

Later streams keep the bit. Streams whose Objects carry no Properties are unchanged.

FIRST_OBJECT fix (review follow-ups). A contributor's FIRST_OBJECT claim (§11.4.2) is honoured only if no lower Object ID was already forwarded in the Subgroup, whichever contributor forwarded it and whether or not this subscriber received it. Objects are published in ascending order (§2.2), so a lower ID proves the claim wrong, and a higher one doesn't. This is decided once per Subgroup, under its lock. Before this, a properties reopen, a gap reopen or a lazy open could set the bit wrongly when two publishers each open with FIRST_OBJECT set.

API

• New: relay.ResetCauseProperties (metric label "properties"). It is added at the end of the enum, so existing values keep their numbers.

Trade-off (documented in the constant's doc and STATUS.md)

Like a §11.4.3 gap reopen, the reset keeps the Objects already written only where RESET_STREAM_AT is in use (MarkReliable). That's quic-go with the extension negotiated. Over WebTransport, or without the extension, unacknowledged Objects on the old stream can be lost. Always setting PROPERTIES would avoid resets entirely, at one byte per Object; you chose against that.

Not in this PR

• Other header fields still come from the first contributor. None of them loses data covered by a MUST, so I left them:
  • END_OF_GROUP: if only a later upstream sets it, the "largest Object is here" hint is lost.
  • Publisher priority: the downstream stream uses the first upstream's priority, including its default.
• FIRST_OBJECT state is lost with the Subgroup set. It lives only while some contributor feeds the Subgroup. If every contributor leaves and a new one arrives, its FIRST_OBJECT claim is not checked against Objects forwarded earlier. Fixing that means keeping per-Subgroup state on the track entry, next to the dedup ledger.
• Expiry vs. reopen ordering: an expired Object that carries Properties can still trigger the reopen before it's dropped. That costs at most one extra reset. Expiry is deliberately checked after the open, because the open can block.

Tests

• Red first: TestFanout_MultiPublisher_ForwardsEveryContributorsProperties failed on the unpatched relay in its "first without, second with" case. It also checks the reopen count and that a new stream isn't marked FIRST_OBJECT; that assertion failed before the follow-up fix.

• Red first: TestFanout_MultiPublisher_FirstObjectOnlyForSubgroupsFirst has two cases:

  • Lower Object forwarded first, filtered out for this subscriber: FIRST_OBJECT must be clear. A second, unfiltered subscriber confirms the Object reached the relay first.
  • A replay starting at Object 5 first, then the true Object 0: FIRST_OBJECT must be set.

  Each case was verified red against the version before its fix. Removing the lowest-ID check fails both FIRST_OBJECT tests.

• Guards: the other two cases pass before and after.

• Metrics: TestResetCauseString covers the new label, and the metrics test checks that a clean Subgroup reports no properties resets.

• Checks: lint, the full suite, -race and make bench-quick all pass, with no allocs/op increase.

🤖 Generated with Claude Code