Repository navigation
updater: the entry after a torn log line is no longer lost with it - #435
Open
rudycelekli wants to merge 1 commit into
Open
rudycelekli wants to merge 1 commit into
rudycelekli wants to merge 1 commit into
Conversation
`Journal::append` opened the update log in append mode and wrote the new line straight after whatever was there. After a power cut mid-append the file ends in a torn line with no newline, so the next entry was glued onto it, and the combined line parsed as neither. `read_all` skips it, so the first outcome recorded after the cut was lost. That is often the rollback the cut caused, which `known_bad` uses to keep `rollback` off a release that already failed its gate. Now a new line is started first when the file does not end in one. Assisted-by: Claude:claude-opus-5-5
This branch has not been deployed
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
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.
What's wrong
Journal::append(updater/src/journal.rs) opensupdate-log.jsonlwithappend(true)and writes the serialised entry plus\n. The doc comment expects power loss mid-append ("a torn final line is tolerated on read"), andread_alldoes skip a torn tail. The problem is the next append. A torn tail has no newline, so the next entry lands on the same line:That combined line parses as neither entry, so
read_alldrops it. The first outcome recorded after the power cut is lost along with the torn one.The entry after a power cut is often the one that matters most: the boot-counter revert, or a gate failure recorded as
RolledBack.Journal::known_badreads those entries to keeprollbackfrom landing on a release that already failed its gate, so losing one can send the board back to a known-bad version.The fix
Before writing,
appendchecks whether the file is non-empty and does not end in\n. If so, it starts a new line first. The file is opened withread(true)as well, so a small helper can read the last byte. Appends still go to the end, because the file is in append mode. The torn line itself is still skipped, as before.Test
journal::tests::an_entry_appended_after_a_torn_line_is_kept: append one entry, write a torn half-line after it (the same waytolerates_torn_final_linedoes), then append aRolledBackentry for 1.1.0. It asserts that both whole entries read back, and thatknown_bad("daemon")is[1.1.0].main: fails, becauserecent()returns 1 entry ("the entry after the torn line was lost").line.insert(0, b'\n'), and that named test failed. Then I put it back.Checks (macOS, aarch64)
cargo test -p updater: 399 passed, 0 failed (lib 244, bins and integration suites 155)cargo clippy -p updater --all-targets -- -D warnings: cleancargo fmt -p updater --check: clean🤖 Generated with Claude Code