Closed Bug 1092074 Opened 7 years ago Closed 7 years ago
Make log shake robust to log parsing failures
8.04 KB, patch
|Details | Diff | Splinter Review|
11.28 KB, text/plain
10.93 KB, text/plain
In bug 1079322 we have an issue where some parsing fails. This makes the whole feature being completely broken: we should avoid this. Instead, we should be as much resilient as possible, and in cases like this one we should: - dump an error in console - continue with the next log
In the event of broken/unexpected things, we would like to have even a partial log set dump. This happens for parsing properties values on Kitkat builds: the current code does all the parsing itself, but the format of storage of properties evolved with Kitkat base system, and this makes LogParser to fail, as documented in bug 1079322. Even if we miss some values, it can still be useful to have the other remaining ones.
Comment on attachment 8514948 [details] [diff] [review] Make LogShake feature resilient to read/parse errors r=gwagner Gregor, I'm r? you since you reviewed previous patches on LogShake. But feel free to redirect if needed :) Move of the changes are just to move code inside the LogShake object, so that we can properly test in xpcshell unit test.
Attachment #8514948 - Flags: review?(anygregor)
With attachment 8514952 [details] and attachment 8514953 [details], we see how the new test fails without the fix. A pending try has been triggered on https://tbpl.mozilla.org/?tree=Try&rev=a7db0463597c Local testing on Kitkat shows this works as expected.
Target Milestone: --- → 2.1 S8 (7Nov)
Attachment #8514948 - Flags: review?(anygregor) → review+
With try green: https://tbpl.mozilla.org/?tree=Try&rev=a7db0463597c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.