Skip to content

A PDF statement travels in a bundle - #99

Merged
kisielewski merged 1 commit into
mainfrom
fix/a-pdf-statement-travels-in-a-bundle
Sep 2, 2026
Merged

A PDF statement travels in a bundle#99
kisielewski merged 1 commit into
mainfrom
fix/a-pdf-statement-travels-in-a-bundle

Conversation

@kisielewski

Copy link
Copy Markdown
Member

A bundle carrying a PDF statement could not be imported, and this is both halves of why.

The first half — the name is filed under the wrong side

statementLanguage in src/exchange/types.ts matched .md alone, so isStatement("content.pdf") was false, partition put it among a version's ordinary files, and the Server refuses content.* there outright — version.file.isStatement, ProblemService.cs. The import dies part way through, after problems have already been created.

src/content/types.ts had already solved this on 2026-08-26, for the same reason and with a comment saying so; the exchange module never got the same amendment. It now asks that module rather than answering the question a third time in a third regex, and statementFileLanguage is exported for it.

The second half — the bytes arrive untyped

uploadAll sent new Blob([bytes]), which has no type, so the multipart part carried application/octet-stream, FileService recorded that, and PackageNames.StatementExtension reads anything that is not application/pdf as Markdown. So even with the first half fixed, a PDF statement is stored under the name content.md — and ProblemPage decides how to draw a statement from that name, so PDF bytes reach markdown-it.

mediaTypeOf names the type from the file's own name, which in a bundle is the version's own file name. Anything not in the table keeps the old application/octet-stream; svg is deliberately absent.

Why partition moved

check:exchange does not compile apply.ts — it talks to the API, and its header says so. With the split inside it, the only thing a check could reach was the predicate, and a file routed to the wrong side stayed invisible. src/exchange/partition.ts is pure and is now driven directly.

This is not only the exchange bundle's problem

Every UVa import stores its statement as content.pdf, so exporting a UVa problem from a real installation already produced a bundle that could not be imported anywhere. The ZawodyWeb converter writes the same name for a problem whose text was a PDF.

What checks it

check:exchange gains the naming cases, the routing through the real partition, the media types, and a cross-repository assertion that every name this product writes is one both sides call a statement. The round-trip fixture's own default statement is now a PDF with a Polish translation beside it.

Sabotaged both ways before it was believed:

Reverted Reddens
statementLanguage to .md-only six checks, naming content.pdf and content-pl.pdf, including the two routing ones
mediaTypeOf to always application/octet-stream the three media-type checks

All twelve offline gate steps pass, and check:ui is green.

Two halves, and either alone leaves it broken: the exchange module read
`.md` only, so `content.pdf` went in with the ordinary files and the Server
refused the publish; and the upload Blob carried no media type, so a PDF that
did arrive was stored under the name `content.md` and drawn as Markdown.

`partition` moves into a module of its own so `check:exchange` can drive the
routing rather than only the predicate it asks.
@kisielewski
kisielewski merged commit f8be56f into main Sep 2, 2026
3 checks passed
@kisielewski
kisielewski deleted the fix/a-pdf-statement-travels-in-a-bundle branch September 2, 2026 03:32
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