Skip to content

quest: import #7573, #7579, #7646 and settle time-addressing's timestamps - #7665

Merged
kixelated merged 1 commit into
mainfrom
quest-import-2026-11-03
Nov 3, 2026
Merged

kixelated merged 1 commit into
mainfrom
quest-import-2026-11-03

Conversation

@kixelated

Copy link
Copy Markdown
Collaborator

Plans the open issues without the quest label (#7573, #7579, #7646). It also records a /quest-import grill that reshaped how time-addressing handles timestamps. Each issue is closed by the PR that finishes its quest, not by this one.

New m1 quests

#7646 points 2 to 4 go to the open ietf-token-auth PR #7211. I'm passing them to that PR's sub-agent, so they aren't in this PR.

Time-addressing edits

model.md, ietf.md, lite07.md, bindings.md, js.md, plus a note in max-age-defaults.md:

  • Every producer write takes a timestamp, and nothing is ever wall-clock stamped. This replaces the 2026-10-27 audit's "producer arguments keep an optional timestamp", which recorded only sequencing.
  • Legacy group IDs pass through verbatim as keys, with no sequence beside them.
  • Scale-less tracks keep lite-07's Timescale 0. Their frames carry their group's key, and max-age counts bare units.
  • One unit per track for keys and frames.
  • moq-mux's catalog producer keeps a broadcast all timed or all scale-less.
  • moq-transport drops our Timestamp property. LOC properties are proxied only between moq-transport peers, and Prior Group ID Gap stays as a best-effort drop signal.
  • Left open: how lite-05/06 map on the way out.

Decisions (2026-11-03, maintainer, /quest-import)

Review

Codex gpt-6.1-sol (medium) via quest review --base origin/main, head 1ad01fa06cf163c2bb00c5c149e425f236f1078d: no findings.

(Written by Claude Opus 5.5)

🤖 Generated with Claude Code

…amps

Plans the three open issues and records the /quest-import grill that
reshaped time-addressing: every write takes a timestamp (no wall-clock
stamping), legacy group IDs pass through verbatim as keys, scale-less
tracks keep lite-07's Timescale 0, and moq-transport drops our Timestamp
property while keeping Prior Group ID Gap as a best-effort drop signal.

New m1 quests: JSON writes take a broadcast-clock timestamp (#7573),
catalog delay is the minimum trail (#7579), a lapsed request token resets
with EXPIRED_AUTH_TOKEN (#7646 point 1), and @moq/net group IDs past 2^53.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@pullfrog

pullfrog Bot commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

This run was cancelled before it finished.

Pullfrog  | View workflow run | via Pullfrog

@kixelated kixelated left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Automated review by review (OpenAI)

Reviewed commit: 1ad01fa

  • quest/m1/time-addressing/model.md:101–108: Legacy publishers may retain sequential group IDs even when frame PTS uses milliseconds, but quest/m1/time-addressing/consumers.md directs HLS/DASH export to place groups by group start rather than first-frame PTS. Those IDs are not presentation timestamps, so the two plans can place legacy segments at incorrect times or collide on the grid. Preserve frame-PTS placement when keys are not known timestamps, or specify an equivalent mapping, and cover legacy ingest in export tests.

The explicit key/clock distinction is a useful direction; aligning the consumer plan with it is simpler than assuming all retained keys are timestamps. Static review only; I did not run tests.

Merged via the queue into main with commit 7d0241d Nov 3, 2026
3 of 6 checks passed
@kixelated
kixelated deleted the quest-import-2026-11-03 branch November 3, 2026 05:07
kixelated added a commit that referenced this pull request Nov 3, 2026
Resolve conflicts with main's time-addressing rules (#7665), the finished
archive epic, and subscribe-ranges' explicit ends. Datagrams keep their own
sequence; the Rust child settles a scale-less datagram's timestamp.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant