Skip to content

Record one response set from a Jellyfin 12.0.0 server, scrubbed to the synthetic values - #503

Closed
iderex wants to merge 1 commit into
mainfrom
record/104-one-response-set-from-a-jellyfin-12-server-b
Closed

iderex wants to merge 1 commit into
mainfrom
record/104-one-response-set-from-a-jellyfin-12-server-b

Conversation

@iderex

@iderex iderex commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Contributes to #104. It does not close it: the comparison in the harness is what closes that issue, and this gives it the first recording to compare against.

Replaces #501, which I close with this. Three things were wrong with it, and each is a reason on its own: its files carried the server's timing header while its own record said three headers were kept; its identifiers were allotted by order of appearance, so the two episodes and the play session shared one synthetic value and the recording could not show that next-up returned a different episode from the one marked; and it landed without the -text rule and the byte assertion that tests/recorded/README.md says the first recording lands with.

What changed

tests/recorded/jellyfin-12.0.0/ holds sixteen responses from a Jellyfin 12.0.0 server, one file per capability of 0272 that has a request to make, and RECORDED.md beside them: what each file shows, which capabilities have no request to record and why, and what was scrubbed in the order tests/recorded/README.md gives. The server was run for the purpose in a container on this machine, with a library of three two-second black videos generated by its own ffmpeg, so the item routes answer with items rather than empty lists and nothing in the recording was made by a person.

Each file is an envelope: capability, method, path, status, the three headers kept, the request body where the call had one, and body as parsed JSON or body_bytes with body_content_type where the answer was image bytes or empty. The date header and the timing header are dropped, because a value that changes on every recording turns each re-recording into a diff nobody can read.

The twelve identifiers that name a thing each got their own synthetic value; the nine digests, entity tags, image tags and the display-preferences id, took the remaining four, the last six sharing the sixteenth. RECORDED.md says which kind of value says nothing about the server when two of them are equal.

.gitattributes gains tests/recorded/** -text with the two Markdown files under the prefix normalised after it, tests/fixture_bytes.rs gains two tests that read every envelope as bytes and refuse a carriage return or a missing final line feed, and the two paragraphs that said the directory was empty and the rule absent, one in the README and one in .gitattributes, now say what is true.

The failure it prevents

A fake server whose every answer was written by hand is measuring the core against a guess, and #104 says what that costs: a field the real server dropped is right in the fixture and wrong on the wire, and the first report comes from somebody running it. A recording from a real server of a supported line is what the comparison reads, and the version it was taken against is written beside it.

Evidence

The scrub check over the tracked subject, run at this head before the commit:

$ bash .github/fixture-scrub/fixture-scrub.sh check
Every rule above was applied to its subject and refused nothing.

The two commands CONTRIBUTING.md names before a push were run in this worktree and are pasted in the first comment below.

What this does not cover

The comparison itself, the harness case that reads these files, and the recording from the 10.11 line, which is #88 and follows in its own pull request on top of this one. The raw recording never entered any tree.

Nobody other than me has read this change.

…e synthetic values (#104)

tests/recorded/ held its procedure and no recording. This is the first: sixteen
responses from a 12.0.0 server run for the purpose, one file per capability of
0272 that has a request to make, with a library of three generated black videos
so that the item routes answer with items. RECORDED.md beside them says what each
file shows, what has no request to record and why, and what was scrubbed in the
order tests/recorded/README.md gives.

WHAT IS IN A FILE IS AN ENVELOPE rather than the bare body: capability, method,
path, status, the three headers kept, the request body where there was one, and
the body as parsed JSON or as a byte count where it was not JSON or was empty. A
comparison of shape, which is what #104 builds over these, needs the status and
the content type as much as the fields, and a bare body carries neither. The
date header and the server's timing header are not kept, because a value that
changes on every recording turns each re-recording into a diff nobody can read.

THE SIXTEEN SYNTHETIC IDENTIFIERS ARE FEWER THAN THE RECORDING HAS, so which
values share one is a choice and it is made rather than left to order of
appearance: the twelve identifiers that name a thing, the server, the views, the
film, the episodes, the series, the season and the play session, get one value
each, and the nine digests, entity tags, image tags and the display-preferences
id, take the remaining four with the last six sharing the sixteenth. Two things
that differ in the recording therefore differ here, and RECORDED.md says which
kind of value says nothing about the server when two of them are equal.

THE FIRST RECORDING LANDS WITH WHAT ITS PROCEDURE SAID IT MUST. The -text rule
for tests/recorded/ joins .gitattributes, with the two Markdown files under the
prefix normalised after it, and tests/fixture_bytes.rs gains the assertion that
makes it bite: every envelope is read as bytes and refused if it carries a
carriage return or does not end in exactly one line feed. The README's paragraph
saying the directory was empty and the rule absent is rewritten to what is now
true, and so is the paragraph in .gitattributes that said the same.

The check that judges these files refused nothing:

    bash .github/fixture-scrub/fixture-scrub.sh check
    Every rule above was applied to its subject and refused nothing.

Contributes to #104. It does not build the comparison in the harness, which is
what closes that issue; it gives it the first recording to compare against.

Signed-off-by: iderex <30603423+iderex@users.noreply.github.com>
@iderex

iderex commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

The two commands before a push, run in the worktree at this head, with cargo fmt -- --check and cargo clippy --locked --all-targets beside them because the gate runs both:

$ cargo fmt -- --check
fmt ok
$ cargo build --locked --all-targets
build rc=0
$ cargo test --locked
10 test result lines, every one of them ok, 0 failed
test rc=0
$ cargo clippy --locked --all-targets
no warning, clippy rc=0

@iderex

iderex commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

Closed in favour of #505: the same change with one sentence of tests/recorded/jellyfin-12.0.0/RECORDED.md reworded, because the document-path check refuses a code span that names the container image, which is not a tracked path. Nothing in the recording moved, and the branch stays as it was pushed.

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