Repository navigation
[bot] Fix tbox journal download: use https, fail loudly on a bad artifact - #606
Merged
Merged
Conversation
The journal URL was plain http; skyhook's :80 went redirect-only 2026-08-17 and copyURLToFile does not follow cross-scheme redirects, so the 301 page was saved as the .gz. unGunzipFile then swallowed the ZipException and startup continued on a fresh empty journal with no error anywhere. - Flip the hard-coded journal URL to https. - unGunzipFile now propagates IOException instead of printing and continuing; streams are closed via try-with-resources (the input stream previously leaked on mid-copy failure). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Member
Author
|
@balhoff If you don't mind taking a look at this, a small change to help us around new thing we hit as we have started shutting down our old HTTP contacts. |
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
2 participants
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.
[bot] Opened by a Claude Code agent on behalf of @kltm.
Fixes #605.
Two changes in
BlazegraphOntologyManager:https. The build-products server serves:80as 301→https only (since 2026-08-17), andFileUtils.copyURLToFiledoes not follow cross-scheme redirects — the download was saving the redirect page as the.gz.unGunzipFilenow propagatesIOExceptioninstead of swallowing it, and closes its streams via try-with-resources (the input stream previously leaked when the gzip header was rejected). On a bad artifact theZipExceptionfires at header time — before any journal bytes are written — and rides declaredthrowsclauses uncaught to each entry point: JVM-fatal in minerva-server,exit(-1)in the CLI. Startup can no longer continue silently on a freshly created empty journal.mvn -pl minerva-core -am compilepasses.unGunzipFilehas no other in-repo callers, and all test constructions passdownloadJournal=false, so no test behavior changes.Deploy note for instances already hit by this: the incident leaves an empty
.jnlon disk, and theexists()guard skips the download when the file is present — delete the bad journal before restarting or the fixed code will reopen it.Known remaining gap (out of scope here, noted in #605): a gzip stream that fails mid-copy (valid header, truncated body) still leaves a partial journal that a later restart would accept; closing that wants an unpack-to-temp-then-rename and/or a size floor.
🤖 Generated with Claude Code
— Posted by Claude Code agent on behalf of @kltm.