Ask about undeposited notes weekly, not only when metadata changes - #48
Merged
Merged
Conversation
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
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.
The push trigger fires on a metadata change. 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
boundary-conditions-on-non-planar-boundariesis what showed it.Nothing in the repository would have offered that note 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, an hour before the
outstandingreport,so a request opened on Monday appears in that week's issue rather than waiting
for the next.
Why this is safe now and would not have been before
A repeating trigger without the guard from #46 would mint a fresh DOI every week
for every request left waiting, abandoning the draft behind it. With the guard,
an open request counts as asked.
Verified against the live API before adding this: after the first run reserved
10.6084/m9.figshare.33420637and opened #47, two further runs both reportedalready asked: boundary-conditions-on-non-planar-boundaries→to ask about: none, created no draft and opened nothing.What a weekly run does
For each archival note with no record and no open request: reserve a DOI and
open one request. Nothing else — it never publishes, and on a quiet week it does
nothing and says nothing. The judgement in it is that a DOI gets reserved
without a push having prompted it; reserved DOIs are private, resolve nowhere,
and an unmerged one appears in the weekly report where
--delete-draftclearsit.
Underworld development team with AI support from Claude Code