fix(java): log a successful compile batch at INFO - a recovered batch must be visible - #6510
Merged
Merged
Conversation
… must be visible The batch failure logs at ERROR but the success logged at DEBUG. After a mid-publish failure (consumers compiled before their dependency project arrived), the next cycle recovers automatically - but at default log level the stale failure ERROR remains the log's last compile line, and a fully green system diagnoses as dead. The batch runs only when the source set changed, so the INFO line is once-per-rebuild, not noise. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
delchev
added a commit
that referenced
this pull request
Aug 4, 2026
…page; popup-blocked prints download instead (#6510) (#6512) The generated print flows opened the rendered PDF at an object URL and revoked it on a 60-second timer - which does not close the tab, it kills the URL under the still-open viewer, so reloading or printing the tab after the timer fails with a dead blob ("the file was removed"). And window.open runs after async work, outside the click's gesture stack, so a popup blocker made the whole print fail silently. The object URL now lives until the SPA page unloads (its natural owner lifetime - a print-sized PDF held until then costs nothing), and a blocked popup falls back to downloading the PDF via a temporary anchor, which browsers always allow. The report/export flows already use the safe immediate-download pattern and are untouched. Co-authored-by: Claude Fable 5 <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.
Problem
The client-Java batch compiler logs a FAILED batch at ERROR, but a successful batch at DEBUG. During a large Publish All, an early batch legitimately fails (consumers compile before their dependency project reaches the registry) and the NEXT cycle recovers automatically - the new artefacts mark the synchronizer dirty and the rebuild succeeds.
At default log level, however, that recovery is invisible: the stale failure ERROR stays the log's last compile line. Observed live: a fully converged instance (all controllers registered, zero errors) was diagnosed as "all beans down" from the log - twice, by different readers, on the same afternoon.
Fix
Log the no-failures batch result at INFO. The batch only runs when the source set changed (the synchronizer's dirty flag), so this is once per rebuild, not log noise.
Notes
🤖 Generated with Claude Code