Do not reserve a second DOI for a note already being asked about - #46
Merged
Merged
Conversation
I dropped this guard when I rewrote the step in #43. It had been added in #42 for the queue design, and the rewrite replaced the whole step without carrying it across. `unreserved()` reads main, and a reserved record only reaches main when a request is MERGED. So between opening a request and merging it the note still looks unreserved, and the next run of the reminder creates a second figshare draft, reserves a second DOI, and opens a second request -- abandoning the first draft. That is the duplicate-mint hazard the whole flow exists to prevent. It is already wrong on the push trigger, where two metadata pushes before a merge are enough. It would be worse on a schedule, which is what prompted looking: a weekly run would mint a fresh DOI for every waiting request, every week. So an OPEN request counts as having asked, and the reminder subtracts those before it reserves anything. The test asserts the guard rather than its wording, since this is the second time the mechanism has been rewritten around it. Underworld development team with AI support from Claude Code
lmoresi
added a commit
that referenced
this pull request
Sep 2, 2026
* Ask about undeposited notes weekly, not only when metadata changes The push trigger fires on a metadata CHANGE, and the condition it cares about is a STATE: archival, published, holding no record. A note that reached that state before this workflow existed -- or whose metadata has simply not moved since -- is never asked about at all. Retrofitting the boundary-conditions note is what showed it. Nothing in the repository would have offered it a DOI; it had to be asked for by hand, and the only reason it was ever offered before that was an unrelated backfill that happened to touch its metadata. So the same question is asked weekly. That is only safe because of the guard merged in #46: a request already open counts as asked, so a note waiting on a decision is not asked again and does not accumulate drafts. Verified before adding this -- two further runs against the live API reported "already asked" and created nothing. Scheduled an hour before the `outstanding` report, so a request opened on Monday appears in that week's issue rather than waiting for the next. Underworld development team with AI support from Claude Code * Read the workflow triggers as text, not YAML pyyaml is not in the test environment, and the triggers are a flat block at the top of the file. I pushed this test failing: the pipe into `tail` masked pytest exit status, so the chain that committed it carried on. Underworld development team with AI support from Claude Code
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.
I dropped this guard when I rewrote the step in #43. It had been added in #42
for the queue design, and the rewrite replaced the whole step without carrying
it across.
unreserved()readsmain, and a reserved record only reachesmainwhen arequest is merged. So between opening a request and merging it, the note
still looks unreserved — and the next run of the reminder creates a second
figshare draft, reserves a second DOI, and opens a second request, abandoning
the first draft. That is the duplicate-mint hazard the whole flow exists to
prevent.
It is already wrong on the push trigger: two metadata pushes before a merge are
enough. It would be worse on a schedule, which is what prompted looking — a
weekly run would mint a fresh DOI for every waiting request, every week.
An open request now counts as having asked, and the reminder subtracts those
before it reserves anything. The test asserts the guard rather than its
wording, since this is the second time the mechanism around it has been
rewritten.
Underworld development team with AI support from Claude Code