Repository navigation
Dev - #54
Merged
Merged
Dev#54
Conversation
Two cases the walkthrough needed and the seeder could not produce: a detection step that FAILED, and the software step reporting PARTIAL because Softcite died while the LM pass carried it. Both are induced by making the external service unreachable from inside the container -- an /etc/hosts entry, added for the duration of one step re-run and removed in a finally. The alternative, writing `failed` onto a job row, produces a demo that falls apart the moment anyone presses the button it exists to show: the logs describe a run that never happened, and Retry re-runs a step that was never broken. Here the failure, the error message, the blocked dependants and the retry are all genuine, and the service is restored before anyone sees the page so Retry SUCCEEDS. Breaking a single step rather than the whole run is what keeps it legible: the rest of the pipeline keeps its good results and exactly one module shows the state being demonstrated. Also fixes three things this run exposed, all of which reported a session problem as something else entirely: - The token expires mid-run. One manuscript's conversion took 28 minutes to fail, after which the next create returned 401 and the run before it had its re-run refused as "Invalid token" -- both printed as ordinary refusals. Renewal is now reactive, on an actual 401. - Renewing on a TIMER instead exhausts the auth limiter (10 attempts per 15 min per IP), and the 429 read as "is the instance running?". - Two logins seconds apart race to write the same session row and 409. That one is retried. --attach re-uses a submission an interrupted run already created, so a half-finished case does not leave a healthy duplicate behind. --only takes a comma-separated list. Verified on the local instance: markdown_convert fail with 7 dependants blocked_by_failure; software_detection partial/softcite_failed; materials_detection fail with 2 dependants blocked. /etc/hosts clean and both services reachable afterwards, so every Retry works.
e453ccf changed what a conflict may say -- only values the manuscript actually prints can contradict the author -- but stored results are not rewritten, so a submission processed earlier keeps showing the old conflicts until its grounding step runs again. Dry run by default, because the price is not obvious: restarting a step takes its dependants with it, and krt_grounding's only dependant is suggestion_generation, which calls the LM. So the fix costs one LM suggestion run per submission, and that number is printed before anything is spent. pdf_analysis deliberately does not depend on grounding, so it is not dragged in. Two things the first version got wrong, both of which read as clean results rather than as errors: - The fix date defaulted to midnight, but e453ccf landed at 16:03 UTC. Three of the four local submissions were grounded between 16:05 and 16:47 that same day, so a midnight cutoff would have called every one of them stale and re-run the lot for nothing. - Conflicts were counted by summing result.data.outcomes, which one submission's grounding result does not carry at all -- reporting 0 conflicts for it. It now reads counts.conflicts, the step's own tally. Local dry run: 4 grounding steps complete, 0 predating the fix. Verified by content rather than by timestamp -- the stored conflicts cite materials-gemini with a manuscriptValue the paper really prints, and carry the post-fix identifierVerdicts/unverifiedIdentifiers fields.
Rewrite the validation-rules reference around the question ASAP asked: what the app recognizes in the IDENTIFIER column and which of those kinds each resource type accepts. Adds the identifier decision flow, the per-kind detection patterns with matching and non-matching examples, the per-type acceptance tables, a Dataset-vs-Other example, a matrix produced by running the validator over 39 values x 14 types, and the known gaps (EMD- form, bare PDB/PMID, RefSeq, catalog-number overlap). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Add ValidationRulesLink, which resolves the deployed repo/branch via /config/source (as ModuleExplainer does) and opens docs/krt-validation-rules.md on GitHub. Shown in the editor summary bar, under identifier-format warnings in the cell modal (anchored to the per-type acceptance section), and at the end of the recognized-formats help panel (anchored to the kinds section). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
No description provided.