4.0 | Runner: fix progress bar when running in parallel #1174
Conversation
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
Rodrigo and me came across this while debugging something completely different. Turns out the split between fixable/fixed error vs warnings, which was necessary in 4.0 to allow for the exit code change, was breaking the progress bar display when parallel processing was enabled. Basically, parallel processing "mocks" the accumulated fixable/fixed error and warning counts via a `DummyFile` before calling `Runner::printProgress()`. Then the `Runner::printProgress()` method calls the `File::getFixed()` method, however, that method doesn't look at the "split" fixed counts, but at the accumulated total fixes, but as this is a mocked `DummyFile`, that number will always be `0`. IIRC, updating the `File::getFixed()` method to calculate the number based on the split fixed errors and warnings was breaking other things, which is why it was left as-is. The down-side of that, as we now discovered, is that the progress bar when running in parallel would always just show a `.` and not the `F` when files were fixed. Either way, this should be fixed now. Includes a test via the new bashunit end-to-end testsuite.
jrfnl
changed the title
This was referenced Sep 16, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
@rodrigoprimo and me came across this while debugging something completely different.
Turns out the split between fixable/fixed error vs warnings, which was necessary in 4.0 to allow for the exit code change, was breaking the progress bar display when parallel processing was enabled.
Basically, parallel processing "mocks" the accumulated fixable/fixed error and warning counts via a
DummyFilebefore callingRunner::printProgress(). Then theRunner::printProgress()method calls theFile::getFixed()method, however, that method doesn't look at the "split" fixed counts, but at the accumulated total fixes, but as this is a mockedDummyFile, that number will always be0.IIRC, updating the
File::getFixed()method to calculate the number based on the split fixed errors and warnings was breaking other things, which is why it was left as-is.The down-side of that, as we now discovered, is that the progress bar when running in parallel would always just show a
.and not theFwhen files were fixed.Either way, this should be fixed now.
Includes a test via the new bashunit end-to-end testsuite.
Suggested changelog entry
Fixed: progress bar wasn't showing files as fixed when running
phpcbfin parallel mode.