Skip to content

Add the route next up is read from, superseding 0010 - #274

Merged
iderex merged 1 commit into
mainfrom
the-route-next-up-is-read-from-272
Sep 1, 2026
Merged

Add the route next up is read from, superseding 0010#274
iderex merged 1 commit into
mainfrom
the-route-next-up-is-read-from-272

Conversation

@iderex

@iderex iderex commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

The issue this belongs to

Closes #272

What changed

docs/decisions/0272-the-route-next-up-is-read-from.md is added and supersedes
0010. It carries 0010's table with one row added - next-up, read from
GET /Shows/NextUp - and the argument for that row: what a first screen loses
without it, what the route costs against both supported lines, and what an absence
of it means for a client that has already reserved the shelf.

0010's Status line gains Superseded by 0272, which is the edit 0001 permits
when a replacing record lands, and docs/decisions/README.md gains the index line.
Nothing else in 0010 changes.

This is the first supersession in this tree, so the spelling comes from 0001 rather
than from a neighbour. Read at the merge base:

git grep -n 'Superseded by 0' -- docs/decisions/ ; echo "exit=$?"
exit=1

git grep -c 'Superseded by nothing' -- docs/decisions/ | wc -l
58

What failure it prevents

0010 is the authority for which paths the core may reach and it has no row for next
up. The kickoff names next up on the first screen a television shows, so the shelf
is going to be built; without a row it is built from a path that is in no
enumeration. #70's test - which fails when the core reaches a host nobody
configured - then judges a smaller surface than the client actually uses, and the
core's own list of what it depends on is wrong by one.

This has already happened once in the cheap form. #39 asked for resume and next up
together, found the resume row in the table and no next-up row, and 0039 had to
refuse half its own scope and say so:

git grep -n 'next up is one of two things' -- docs/decisions/0039-the-page-the-item-and-what-next-up-is-not.md
docs/decisions/0039-the-page-the-item-and-what-next-up-is-not.md:225:So next up is one of two things and neither is this record's: either 0010 is

The expensive form is the same absence met at a call site instead, where the
cheapest way out is to write the path and move on.

Evidence

Every reading in the record was taken against the two commits 0010 names, through
the server's own repository over the network rather than through a clone. The two
lines first, so the rest is anchored:

A=1fbd8739292cce610231be93daf43368733edf63    # the 10.11 line
B=c3ed1407ca698b0905de99da87b67415e6a62dbd    # the 12.0 line
for r in $A $B; do
  gh api "repos/jellyfin/jellyfin/contents/SharedVersion.cs?ref=$r" --jq '.content' \
    | base64 -d | grep AssemblyVersion | head -1
done
[assembly: AssemblyVersion("10.11.11")]
[assembly: AssemblyVersion("12.0.0")]

The route exists on both and answers with the type 0039 already fixes:

for r in $A $B; do
  gh api "repos/jellyfin/jellyfin/contents/Jellyfin.Api/Controllers/TvShowsController.cs?ref=$r" \
    --jq '.content' | base64 -d | grep -n -A2 'HttpGet("NextUp")' | grep 'HttpGet\|ActionResult'
done
76:    [HttpGet("NextUp")]
78-    public ActionResult<QueryResult<BaseItemDto>> GetNextUp(
75:    [HttpGet("NextUp")]
77-    public ActionResult<QueryResult<BaseItemDto>> GetNextUp(

The cost the record spends most of its argument on, which is a default rather than
a server behaviour:

for r in $A $B; do
  gh api "repos/jellyfin/jellyfin/contents/Jellyfin.Api/Controllers/TvShowsController.cs?ref=$r" \
    --jq '.content' | base64 -d | sed -n '/HttpGet("NextUp")/,/^    {/p' \
    | grep -E 'enableResumable|enableRewatching' | sed -E 's/^ +//'
  echo "--"
done
[FromQuery] bool enableResumable = true,
[FromQuery] bool enableRewatching = false)
--
[FromQuery] bool enableResumable = true,
[FromQuery] bool enableRewatching = false)
--

The remaining blocks - the paging parameters, the base route and the authorization,
and the one parameter the two lines disagree about - are in the record with the
command that produced each.

Every link the record names resolves:

grep -oE '\]\([0-9]{4}-[a-z0-9-]+\.md\)' docs/decisions/0272-the-route-next-up-is-read-from.md \
  | tr -d ']()' | sort -u | while read -r p; do
    [ -f "docs/decisions/$p" ] && echo "OK   $p" || echo "MISSING $p"; done
OK   0001-decision-records.md
OK   0003-what-the-core-does-not-do.md
OK   0004-the-error-vocabulary.md
OK   0009-the-concurrency-model.md
OK   0010-the-server-surface-and-what-an-absence-does.md
OK   0028-the-address-a-person-typed.md
OK   0036-the-device-identity-and-who-supplies-it.md
OK   0038-retry-and-backoff.md
OK   0039-the-page-the-item-and-what-next-up-is-not.md
OK   0243-the-means-a-certificate-is-validated-with.md

The check that reads those targets was run on this branch and passed:

bash .github/doc-paths/doc-paths.sh check | tail -3

Every path these documents name resolves against the tracked set.
EXIT=0

What this does not cover

The sixteen carried rows were not re-derived. Their readings were taken in 0010
against the same two commits, that record keeps its text, and this change carries
the rows without retaking the evidence behind them. The record says so in its own
words rather than leaving a reader to assume otherwise. What was retaken is the two
line tips and everything about the route being added.

No implementation. Nothing in this change makes a request, and nothing in the
tree does. The core reaches no network at all today, which is why the row is
decided rather than discovered.

The parameter is not fixed. enableResumable defaults to a set that overlaps
the resume list, which the record states as a cost of the route; what a call asks
for is #39's, and choosing the value here would decide one issue inside another.

Nothing here is a statement about a running server. Every line was read out of
the server's source at two commits. The comparison against a real server is #104.

0039 is untouched. Its own reversal condition names this case and says what is
owed when it fires - a statement of what next up is in terms of the page and the
item - and the new record supplies it. Whether 0039 should also carry a pointer to
it is that record's question and a change to a file this one does not open.

No check reads any of this. There is no check over docs/decisions/, so
nothing refuses a record whose index line is missing or whose supersession is
spelled wrong. The Documents name paths that resolve check reads link targets and
code spans and is what stands behind the resolution above, and it reads neither a
Status line nor an index.

Who has read it

Nobody other than the author has read this change.

0010 is the authority for which paths the core may reach and it has no row for
next up. The kickoff names next up on the first screen a television shows, so the
shelf gets built either way; without a row it is built from a path in no
enumeration, and #70's test then judges a smaller surface than the client uses.
0039 already met the absence and had to refuse half of #39's scope over it.

0272 carries 0010's table with one row added - next-up, GET /Shows/NextUp,
assertion - and the argument the row is for: the route exists on both supported
lines and answers with the item type and the page 0039 already fixes, a 404 on it
is capability-absent because the path carries no caller-supplied identifier, and
its enableResumable default asks for a set that overlaps the resume list, which is
a cost of the route stated here and a parameter left to #39.

The whole table is carried because whole-record supersession is the only shape
0001 offers; #267 is where a partial one is asked for and this does not invent it.
The readings behind the sixteen carried rows were not retaken, which the record
says of itself. 0010 keeps its text and gains Superseded by 0272, which is the
edit 0001 permits when a replacing record lands.

Signed-off-by: Nils Lehnen <30603423+iderex@users.noreply.github.com>
@iderex
iderex merged commit 2ed77e6 into main Sep 1, 2026
24 checks passed
@iderex
iderex deleted the the-route-next-up-is-read-from-272 branch September 1, 2026 05: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.

Decide the route next up is read from, as a record that supersedes 0010

1 participant