Triaged by cause rather than by file. Three of them were product defects and are fixed (fa904a3bb); the rest are catalogued here with what is actually known about each.
First, three numbers that are not the same number
The summary line counts assertion failures, not tests. "104 failures" was 74 failing tests. Earlier reports in this project quoted 122, 118, 105 and 99 interchangeably — all assertion counts, none of them the number of broken tests. Use grep -c "^Test Case .* failed" on unique lines.
Fixed: three product defects
| Defect |
Consequence |
inferLevel matched warning, warn:, warning: — not [WARN] |
Every [WARN] line in a plain-text log showed as info. The level chip lied and filtering to warnings hid the warnings. Every other level matched its bare word; warn alone was strict. |
parseLineTimestamp had no pattern for a zoned ISO timestamp |
TriosLogBus writes ...Z. The LOGS tab could not order its own bus. |
rotateIfNeeded returned early when the live file was absent |
It took age-based archive cleanup with it, so a family whose current log was deleted or renamed kept its archives forever — the unbounded growth the retention work exists to stop, in the one case nobody watches. |
Fixed: two locale-dependent test defects
Calendar.current on a Thai-region machine (en_TH) is the Buddhist era: a correctly parsed 2026 came back as 2569 and the test failed on a value the parser got right. The ISO test asserted hour 12 for 12:00:00Z while reading in local time, which is 19:00 in Bangkok. The instant under test is absolute; only the reading was locale-dependent, so the reading is pinned and the parser left alone.
Worth stating because it generalises: any assertion that reads a date through Calendar.current is a machine-configuration test wearing an assertion.
Remaining, and the one thing every one of them has in common
Every class sampled fails in isolation as well as in the full run, so there is no cross-test contamination to chase:
| Class |
full run |
alone |
note |
| LogsTabViewTests |
12 |
13 |
see below |
| LocalAuthProviderTests |
9 |
13 |
worse alone |
| ModelHealthServiceTests |
8 |
9 |
environment: no key, health reads unknown(not configured) |
| ChatFailureTests |
5 |
6 |
|
| ModelConfigurationStoreCrossProviderTests |
4 |
6 |
worse alone |
| WarmupVolatilityTrackerTests |
3 |
3 |
|
| MemoryStoreFTSTests |
3 |
3 |
one is table memories already exists — shared DB |
| StreamingContextWatchdogTests |
2 |
2 |
|
| ConversationEncryptionTests |
2 |
2 |
No stored settings data |
Two classes fail more alone than together, which is order dependence in the direction nobody looks for: the full run masks failures rather than causing them.
Analysed and deliberately not changed
incrementalRefresh hides a trailing line with no newline, treating it as half-written, while the initial parse of the same file shows it. Two readings of one file that disagree.
Waiting for the terminator is right for a tail — you must not show a torn line — and wrong for a quiescent log whose last line never gets one, which then stays invisible forever. The fix is a provisional last line that is replaced rather than duplicated when the rest arrives. That is a design change, not a repair, and it should be decided rather than patched into whichever shape makes the test green.
Follows #1275, #1276, #1277.
Triaged by cause rather than by file. Three of them were product defects and are fixed (
fa904a3bb); the rest are catalogued here with what is actually known about each.First, three numbers that are not the same number
The summary line counts assertion failures, not tests. "104 failures" was 74 failing tests. Earlier reports in this project quoted 122, 118, 105 and 99 interchangeably — all assertion counts, none of them the number of broken tests. Use
grep -c "^Test Case .* failed"on unique lines.Fixed: three product defects
inferLevelmatchedwarning,warn:,warning:— not[WARN][WARN]line in a plain-text log showed as info. The level chip lied and filtering to warnings hid the warnings. Every other level matched its bare word; warn alone was strict.parseLineTimestamphad no pattern for a zoned ISO timestampTriosLogBuswrites...Z. The LOGS tab could not order its own bus.rotateIfNeededreturned early when the live file was absentFixed: two locale-dependent test defects
Calendar.currenton a Thai-region machine (en_TH) is the Buddhist era: a correctly parsed 2026 came back as 2569 and the test failed on a value the parser got right. The ISO test asserted hour 12 for12:00:00Zwhile reading in local time, which is 19:00 in Bangkok. The instant under test is absolute; only the reading was locale-dependent, so the reading is pinned and the parser left alone.Worth stating because it generalises: any assertion that reads a date through
Calendar.currentis a machine-configuration test wearing an assertion.Remaining, and the one thing every one of them has in common
Every class sampled fails in isolation as well as in the full run, so there is no cross-test contamination to chase:
unknown(not configured)table memories already exists— shared DBNo stored settings dataTwo classes fail more alone than together, which is order dependence in the direction nobody looks for: the full run masks failures rather than causing them.
Analysed and deliberately not changed
incrementalRefreshhides a trailing line with no newline, treating it as half-written, while the initial parse of the same file shows it. Two readings of one file that disagree.Waiting for the terminator is right for a tail — you must not show a torn line — and wrong for a quiescent log whose last line never gets one, which then stays invisible forever. The fix is a provisional last line that is replaced rather than duplicated when the rest arrives. That is a design change, not a repair, and it should be decided rather than patched into whichever shape makes the test green.
Follows #1275, #1276, #1277.