Skip to content

A file reference is an id, and the address is this side's to build - #106

Merged
kisielewski merged 1 commit into
mainfrom
feat/a-file-reference-is-an-id
Sep 6, 2026
Merged

A file reference is an id, and the address is this side's to build#106
kisielewski merged 1 commit into
mainfrom
feat/a-file-reference-is-an-id

Conversation

@kisielewski

Copy link
Copy Markdown
Member

After importing the demonstration bundle, the figures in four problem statements
did not display. Neither the export nor the import was at fault — the archive's
PNGs are real, their checksums match, they are scope: participant, and each
statement references one by bare name exactly as content/reference.ts writes
and ContentView resolves.

The Server published /api/v1/files/<id>, relative to its own origin, and
this side put it into <img src> verbatim. Served from anywhere else, the
browser asked the application for the bytes and got the single-page shell.

AlgoJudge/AlgoJudge-Server#97 stops sending an address. This reads the id.

What changes

Attachment, ProblemFile, InstanceLogo and InstanceFont carry fileId
and no url. Every consumer joins it itself — fileApi.url(f.fileId), which is
absolute because baseUrl carries the API's origin — and hands the result to the
DOM. No proxy, in Vite or anywhere else.

The renderer takes an address rather than a reference. ReferencedFile in
content/reference.ts is { name, mimeType, address }, because a stored file,
one staged in the editor and unpublished, and the mark this application ships
with are three answers to one question. They were being spelled url ?? "#" and
a placeholder.

The export stops reading an address. collect.ts said in its own comment
that it wanted to go through fileApi and could not, because the DTO published
an address and no id. It does now — and compares the checksum at the fetch.
Before, a relative address reached the application, the SPA shell came back with
response.ok === true, and the HTML was bundled as the file's bytes; the
failure surfaced at somebody else's import as "the archive is damaged".

Two things the fake could not show

  • A problem's attachments answered "#". No figure had ever rendered in any
    browser check, so this class of defect was structurally invisible here.
    FakeFiles.seedBytes seeds a real one-pixel PNG and the figure draws.
  • The package archive named no file, so exporting a version with a package
    threw "has not been stored". It carries its fileId now.

Verification

lint (silent), lint:deps, typecheck, build, check:i18n, check:content,
check:exchange, check:ranking, and check:ui.

verify-exchange reddened once and it was mine: the export goes through
fileApi now, the fake sleeps 200 ms per call by design, and the script's fixed
four-second wait was landing inside that. It waits for the archive instead,
which is what scripts/verify/README.md prescribes.

sign-in-redirect fails in any checkout carrying a .env with
VITE_APP_API_BASE_URL — the provider challenge is built from that origin and
the redirect leaves for a Server the fake run has not got. Confirmed unrelated:
it passes with the variable unset, and CI has no .env.

Measured on a live stack. The bundle imported through the manager's import
screen; all four figures 200 image/png with decoded widths 1280, 1070, 1260,
1184. Measured again on the production topology — a page on algojudge.test,
images from api.algojudge.test — and all four drew there too, the
SameSite=Lax session cookie riding along because the two share a registrable
domain.

Four answers named a file by where to fetch it, relative to the Server's
own origin — so a figure in a statement asked the application for its
bytes and was answered with the single-page shell.

The renderer takes an address rather than a reference, because a stored
file, one staged in an editor and the mark this application ships with are
three different answers to the same question.
@kisielewski
kisielewski merged commit dca1f4b into main Sep 6, 2026
3 checks passed
@kisielewski
kisielewski deleted the feat/a-file-reference-is-an-id branch September 6, 2026 21:33
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