Current state
clients/src/gcp.rs parse_entries silently substitutes Utc::now() when a log entry's timestamp field is absent or unparseable, making stale entries appear recent in the TUI. This is a known data-integrity bug. The test parse_entries_missing_timestamp_uses_now exists and passes — it asserts entries[0].timestamp >= before && entries[0].timestamp <= after, which validates the silent substitution as the correct contract. The test gives a false green: it passes when the implementation is broken, and would continue to pass even if the substitution were removed and replaced with an error return. A developer trying to fix the bug cannot use this test to drive the fix — it will pass either way.
Ideal state
- The test either asserts
parse_entries returns Err when a timestamp is absent (if that is the correct contract) or is marked #[ignore] with a comment linking to the bug issue and explaining that the current behavior is a known defect
- The test does not encode the silent substitution as a permanent behavioral contract
- When the underlying bug is fixed, the test is updated to match the corrected behavior
Out of scope
- Fixing the
parse_entries implementation (that is the subject of the separate bug issue tracking the timestamp substitution)
Starting points
clients/src/gcp.rs lines 182–190 — parse_entries_missing_timestamp_uses_now test
QA plan
- Open
clients/src/gcp.rs — expect parse_entries_missing_timestamp_uses_now to either assert Err or be marked #[ignore] with an explanatory comment referencing the bug issue
- Run
cargo test -p clients — expect the suite to pass (either the assertion is now correct, or the test is explicitly ignored)
Done when
parse_entries_missing_timestamp_uses_now does not assert that silent Utc::now() substitution is the correct behavioral contract.
Current state
clients/src/gcp.rsparse_entriessilently substitutesUtc::now()when a log entry's timestamp field is absent or unparseable, making stale entries appear recent in the TUI. This is a known data-integrity bug. The testparse_entries_missing_timestamp_uses_nowexists and passes — it assertsentries[0].timestamp >= before && entries[0].timestamp <= after, which validates the silent substitution as the correct contract. The test gives a false green: it passes when the implementation is broken, and would continue to pass even if the substitution were removed and replaced with an error return. A developer trying to fix the bug cannot use this test to drive the fix — it will pass either way.Ideal state
parse_entriesreturnsErrwhen a timestamp is absent (if that is the correct contract) or is marked#[ignore]with a comment linking to the bug issue and explaining that the current behavior is a known defectOut of scope
parse_entriesimplementation (that is the subject of the separate bug issue tracking the timestamp substitution)Starting points
clients/src/gcp.rslines 182–190 —parse_entries_missing_timestamp_uses_nowtestQA plan
clients/src/gcp.rs— expectparse_entries_missing_timestamp_uses_nowto either assertError be marked#[ignore]with an explanatory comment referencing the bug issuecargo test -p clients— expect the suite to pass (either the assertion is now correct, or the test is explicitly ignored)Done when
parse_entries_missing_timestamp_uses_nowdoes not assert that silentUtc::now()substitution is the correct behavioral contract.