Skip to content

quest(net): record Route job-retirement decision - #7770

Merged
kixelated merged 4 commits into
mainfrom
quest/m1/api-audit/route/handle
Nov 4, 2026
Merged

kixelated merged 4 commits into
mainfrom
quest/m1/api-audit/route/handle

Conversation

@kixelated

@kixelated kixelated commented Nov 3, 2026 •

Copy link
Copy Markdown
Collaborator

Problem

One Route handle required a job's exact route to inherit its prefix route's instance by default, and every Route to keep its instance for its lifetime. But a job that ends and restarts beneath the same prefix restarts its group sequences, so it must not reuse that instance. The dependent takeover quest owned that retirement safety while requiring this quest to land first. Keeping the inherited default with independent restarts would also need a bounded way to tell a path's first job from a later run; a map of ended paths grows with serial requests over a long-lived prefix.

No publishing API implementation is included. This PR records the decision so the quest can be implemented.

Decision

  • ✅ Decided 2026-11-03 (maintainer): request.route(options) mints a fresh instance by default, as Request::prepare does today, so a job that ends and restarts beneath a prefix gets a new instance for its restarted sequences.
  • An explicit stable instance in the options is only for a caller that continues its sequences.
  • Ending a job's route withdraws only that path. The prefix route stays open and keeps answering later requests, each with an independent job lifetime, and the origin keeps no history of ended paths.
  • The existing predecessor handling stays until the takeover quest replaces it.

Approach

  • handle.md: the Plan gains a ✅ A job's instance item, with both the instance default for a restarted job and the fact that ending a child does not make its prefix terminal. The inherited-default sentence in Prefix routes and the ## Waiting section are removed.
  • announce-takeover.md: that quest assumed the handle quest provided inheritance by default. Its Inheriting the instance item now says that carrying the claim's instance onto the job's route is its own change. That change must keep the decided properties: a restarted job still gets a fresh instance, and job lifetimes stay independent without per-path history of ended jobs. Its ## Required line now describes the fresh default.
  • doc/concept/identity.md already describes each requested path as published under a fresh instance, so it needs no change.

Impact

  • Public API: none in this PR. The breaking Route migration is the quest's later implementation.
  • Wire: none.
  • No changes to other PRs, package versions, checks, or CI policy.

Validation

  • quest check --base origin/main: passed (563 documents).
  • sh/markdown.sh check (after bun install --frozen-lockfile): passed.
  • Merged origin/main (b8e77d803f) without conflicts. moq-dev/moq#7678 (announcements as a path listing) is still open, not on main, so it does not affect this diff.
  • From the earlier checkpoint: two temporary model probes showed that ranking by epoch already behaves as specified. They also showed that re-announcing a restarted job under the prefix instance lets a retired pin resolve (reused_instance=true, retired_pin_resolves=true), while the current fresh instances do not. That is why the decision keeps fresh instances. The committed Rust source is unchanged.
  • Interop was not run: no wire, binding, or runtime code changed.

Overlap audit

Alternatives

  • Rejected: keep the inherited default and make the prefix terminal once a materialized job ends, so applications recreate the prefix with a fresh instance. This bounds history but changes how long-lived services behave.
  • Rejected: keep both inherited defaults and automatic independent restarts. This needs ended-path history, or a bounded retirement design moved into this prerequisite before implementation.

Follow-ups

None added. Continuing a claim's readers on the job's route remains the existing takeover quest.

Review

  • quest review round 1 (codex gpt-6.1-sol, medium) at 7e43fe0a7f: 0 findings.

(Written by Claude Opus 5.5)

kixelated and others added 2 commits November 3, 2026 14:46
Co-Authored-By: GPT-6.1 Sol <noreply@openai.com>
@kixelated kixelated changed the title One Route handle quest(net): record Route job-retirement decision Nov 3, 2026
kixelated and others added 2 commits November 3, 2026 17:11
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Record the maintainer's 2026-11-03 decision on One Route handle and update announce takeover, which assumed handle inherited the prefix route's instance.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@kixelated
kixelated marked this pull request as ready for review November 4, 2026 01:14
@coderabbitai

coderabbitai Bot commented Nov 4, 2026

Copy link
Copy Markdown
Contributor

Warning

Review limit reached

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Next included review available in 11 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used all 4 included reviews currently available.

Learn how review limits work.

Review configuration:

Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 3ee5f0e9-1142-4ab6-a79d-86de601a79cd
Commits

Reviewing files that changed from the base of the PR and between b8e77d8 and 7e43fe0.

Files selected for processing: 2
  • quest/m1/announce-takeover.md
  • quest/m1/api-audit/route/handle.md
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

Share

@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 head: 7e43fe0.

No actionable finding in this planning change. The route-handle quest records a fresh default instance and independent job lifetimes, while the dependent takeover quest owns preserving those properties when it supplies inherited identity. Verification: static GitHub inspection of the plans and current ownership paths only; I did not run the model probes or interop tests.

(Written by review (OpenAI))

@pullfrog pullfrog Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

✅ No new issues found.

Reviewed changes

  • Job instance default recorded: quest/m1/api-audit/route/handle.md now states that request.route(options) mints a fresh instance by default, that ending a job withdraws only its path while the prefix stays open with no ended-path history, and that an explicit stable instance is only for continuing sequences.
  • Takeover quest updated: quest/m1/announce-takeover.md now attributes carrying the prefix route's instance to the takeover quest and requires fresh instances for restarted jobs with independent lifetimes.

The claims match the source: Request::prepare mints a fresh instance (rs/moq-net/src/model/origin.rs:5969), Requests::route() is the default with update_route crate-private (origin.rs:5771, origin.rs:5794), and doc/concept/identity.md:167-170 already describes each prepared job as a fresh instance. Other quest references to inheriting a claim's instance describe the takeover quest's end state, so they remain accurate.

Pullfrog  | View workflow run | Using deepseek-v4.1-flash-1017 (free via Pullfrog for OSS) | 𝕏

@kixelated
kixelated added this pull request to the merge queue Nov 4, 2026
Merged via the queue into main with commit 148f733 Nov 4, 2026
12 checks passed
@kixelated
kixelated deleted the quest/m1/api-audit/route/handle branch November 4, 2026 03:04
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