fix(js/net): key the publisher's TRACK_INFO cache by broadcast, not path

[kixelated]

Completes quest/m1/2985 and deletes the quest file.

Closes #2985

Summary

Root cause. The moq-lite publisher memoized each track's immutable TRACK_INFO in a Map keyed by `${broadcastPath}\0${trackName}`. That key is a path, and a path outlives the broadcast on it: Origin.publish swaps the front under an existing key, so a republish left the entry in place and every later TRACK request was answered with the predecessor's priority, maxAge, and timescale.

runFetch reads the same cache to pick the timescale it converts frame timestamps into, so the successor's frames were quantized onto the predecessor's grid. runSubscribe resolves track.info() fresh, so the two paths disagreed about the same track on the same connection.

Fix. Key the cache on the routing front (broadcast.Consumer identity) instead of the path, in a WeakMap so an entry's lifetime is exactly the broadcast's. That is the same identity runAnnounce already diffs on to emit ended-then-active for a republish, so discovery and metadata now agree on what a generation is. #resolveTrackInfo takes the front rather than re-looking it up, which also closes a smaller window in runFetch: it resolved the front, then #resolveTrackInfo resolved it again, so a replacement landing between the two lookups could pair one generation's metadata with the other's frames.

This is the third of the three sites #2985 lists. The other two are already fixed on dev: runAnnounce holds Map<Path.Valid, broadcast.Consumer> and diffs on the front, and ietf/publisher.ts records the front each refusal was about in offered. The issue's suggested #2610 epoch remedy is gone (#3225 removed Epoch from the moq-lite draft as spec-only), so this is the local fix instead: no wire-level identity needed.

Branch

Targets dev because the m1 questline is dev-based and the fix is written against dev's origin/front model (broadcast.Consumer.resolveTrackInfo, the front-keyed announce diff). main carries the same path-keyed cache and picks this up on the next dev merge.

The same defect exists in rs/moq-net, and is NOT fixed here

Verified against a running moq-relay (JS publisher -> relay -> JS subscriber). After the fix the JS publisher serves the successor's timescale on the wire, but the subscriber's track("video").info() through the relay still returns the predecessor's {priority: 1, timescale: MILLI, maxAge: 1000}.

The relay is not doing the path-keyed thing; it fails a different way in the same family. resume::Consumer::poll_info in rs/moq-net/src/model/resume.rs resolves info from segment zero and never from the newest, while every data read (fetch_group, subscribe) routes to the newest segment. origin.rs's run_front Step::Splice arm does re-resolve source.track(&name).info() for the successor before resume.takeover(&track), so the relay learns the successor's info and then discards it. Reached via TrackInfoServe in rs/moq-net/src/lite/publisher.rs -> broadcast::Consumer::track (spliced) -> track::Querying::poll_ok -> resume.poll_info. The relay's upstream side is correct.

There is no open tracker for it: #2991 is about sequence continuity across replacements and says nothing about track::Info, and #2610 (which spec'd the epoch answer) is closed as completed with no epoch in rs/. It wants its own issue against resume::Consumer::poll_info, which I have not filed.

Wire behavior changes

No encoding change. What a peer observes differently: after a broadcast is replaced at a path, a TRACK request now returns the successor's TRACK_INFO rather than the predecessor's, and FETCH serves frames on the successor's timescale. Previously the publisher served the first generation's metadata for the rest of the session.

The drafts/draft-lcurley-moq-lite.md commit only qualifies existing caching advice: the Track Stream section told a subscriber to cache TRACK_INFO keyed by broadcast path and track name for the life of the session, which is the shape that goes stale here. It adds no normative requirement and no format change. Drop that commit if you would rather the spec text move separately.

Cross-Package Sync

• js/net <- rs/moq-net: this is the js side of a defect that exists on both. The Rust side is described above and deliberately not fixed here.
• drafts/: the wire format is unchanged, so no draft update was required; the one included is a clarification, not a format change.
• js/{watch,publish}, demo/web: no API change, nothing to pair.

Test plan

• Two regression tests in js/net/src/integration.test.ts, both failing on dev and passing with the fix:
  • track info follows a republished broadcast: priority came back 1 instead of 7.
  • fetch uses the republished track's timescale: a 1234us timestamp came back as 1000us, quantized onto the predecessor's millisecond grid.
• just fix, just check, just test: all pass. Rust and Python were skipped by the diff scoping (no crates affected), which is expected for a js + drafts diff.
• just drafts check: passes.
• Manual, against a real moq-relay over the WebSocket/qmux transport, replacing a broadcast on a live path. With the fix reverted the fetched frame arrives as 1000us; with the fix it arrives as 1234000us, i.e. the publisher wrote 1234 ticks on the successor's MICRO grid and only the relay's own stale metadata rescaled them. That is what isolated the remaining staleness to rs/moq-net.

Not run

• just test smoke-full: no wire, moq-ffi, or gateway change.
• Browser exercise via just dev: no watch/publish/UI surface changed.

(Written by claude-opus-5[1m])

🤖 Generated with Claude Code

https://claude.ai/code/session_01DLtoPv9B3779kGxLFTUGHR

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-05T04:33:54.790522Z	d44e19c	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: d44e19cd27

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Decouple cache invalidation from route retraction

When a persistent prefix route remains advertised while the application replaces a broadcast beneath it, no ANNOUNCE_END occurs: the Announce section defines routes as capability rather than inventory. A subscriber following this new rule therefore retains the predecessor's TRACK_INFO and can decode the successor's timestamps and retention metadata incorrectly. Define a generation signal or constrain cache validity independently of announcement lifetime instead. (Written by GPT-5.6 Sol)

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Record the cache-lifetime change in the changelog

This adds semantic guidance governing when TRACK_INFO caches must be discarded, but the moq-lite-06 changelog has no corresponding entry, so revision readers cannot discover the behavior change. Add a concise factual bullet to the in-progress changelog section. (Written by GPT-5.6 Sol)

AGENTS.md reference: drafts/AGENTS.md:L77-L81

Useful? React with 👍 / 👎.