The reserve must write the DOI into the article, not only its metadata - #49
Merged
Merged
Conversation
The first live reserve opened a request whose tests failed, correctly: `test_the_pdf_carries_the_archival_doi_once_a_note_is_deposited` compares the article's front matter `doi:` against `archive_doi` in metadata.yml, and the reserve had written only the second. That is not a test being fussy. The article's front matter is where the PDF's title page takes the DOI from, so publishing from that state would have produced an archival PDF with no DOI on it -- the one thing the reserve-before-build order exists to prevent. sync_archival.py already copies both the DOI and archived_at across; it was simply never called, being a script somebody ran by hand. The reserve now runs it, so the request carries both files and the publish still needs nothing written back afterwards. Found by running the flow against the live API rather than by reading it. Underworld development team with AI support from Claude Code
…front-matter # Conflicts: # tests/test_migration.py
lmoresi
added a commit
that referenced
this pull request
Sep 2, 2026
The reserve that opened this request wrote only metadata.yml, so the article's own front matter carried no DOI -- and that is where the PDF's title page takes it from. Publishing from that state would have deposited a PDF with no DOI on it. Fixed at source in the reserve itself (#49); this brings the request that found it up to the same state, rather than throwing away a DOI that is already reserved. Underworld development team with AI support from Claude Code
lmoresi
added a commit
that referenced
this pull request
Sep 2, 2026
* Deposit: boundary-conditions-on-non-planar-boundaries A draft and a DOI are reserved for this note; neither is public. The identifiers are in its metadata.yml, so merging this approves the deposit and records it in one step. Opened automatically because the note is on main without a record. * Write the reserved DOI into the article front matter too The reserve that opened this request wrote only metadata.yml, so the article's own front matter carried no DOI -- and that is where the PDF's title page takes it from. Publishing from that state would have deposited a PDF with no DOI on it. Fixed at source in the reserve itself (#49); this brings the request that found it up to the same state, rather than throwing away a DOI that is already reserved. Underworld development team with AI support from Claude Code --------- Co-authored-by: underworld-technical-notes <help@underworldcode.org> Co-authored-by: lmoresi <louis.moresi@anu.edu.au>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first live reserve opened #47, and its tests failed — correctly.
test_the_pdf_carries_the_archival_doi_once_a_note_is_depositedcompares thearticle's front matter
doi:againstarchive_doiinmetadata.yml, and thereserve had written only the second.
That is not a test being fussy. The article's front matter is where the PDF's
title page takes the DOI from, so publishing from that state would have produced
an archival PDF with no DOI on it — the one thing the reserve-before-build
order exists to prevent.
sync_archival.pyalready copies both the DOI andarchived_atacross; it wassimply never called, being a script somebody ran by hand. The reserve now runs
it, so a request carries both files and the publish still needs nothing written
back afterwards.
Found by running the flow against the live API rather than by reading it — which
is the argument for having done #47 by hand before turning on the schedule.
Underworld development team with AI support from Claude Code