Repository navigation
drift/02a: backfillWorkout no longer drops stored steps - #20
Merged
Merged
Conversation
WorkoutDetector.backfillWorkout rebuilds the WorkoutRow through the initializer and passed every field except steps, silently nulling stored per-session steps on any backfill — and making an all-fields-present row compare != to its input, so callers rewrote rows that needed no write. The doc comment promised the opposite; the Kotlin twin (real.copy(...)) was never affected. Field-by-field audit of WorkoutRow (13 fields): steps was the only one dropped. Regression tests cover steps survival and the ==-when-complete contract; red before the fix (2 failures), full suite 1426/0 after. Part of the drift-control plan in #17 (step 2). Co-Authored-By: Codex <noreply@openai.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
9 of 10 tasks
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.
Fixes #16 (plan step 2 of #17).
WorkoutDetector.backfillWorkoutrebuilds theWorkoutRowthrough the initializer and passed every field exceptsteps— so any backfill silently nulled stored per-session steps, and an all-fields-present row compared!=to its input, making the caller rewrite a row that needed no write (upsertWorkoutsthen persistedsteps = NULL). The doc comment promised the opposite. The Kotlin twin (IntelligenceEngine.backfillWorkoutFromDetectedBout,real.copy(...)) was never affected — a drift where Kotlin is right and Swift loses data.The fix
Field-by-field audit of
WorkoutRow(13 fields) against the initializer call:stepswas the only one dropped. The fix passessteps: real.stepsthrough; one overclaiming clause in the doc comment tightened (unchanged means no available value was filled).Verification
filled.stepswasnil, expected4200; full-row==contract broken).real.copy(...).Review
Codex review (read-only, independent): verdict green. Confirmed: the 13-field audit (nothing else dropped), test sharpness against the original bug (both tests catch it), the single production callsite's write behavior (
backfilled != hit→ the fix stops both the data loss and the previously spurious rewrite), Kotlin needs no change. Its one small finding (overclaiming doc clause) is folded in.Part of the drift-control plan in #17.
🤖 Generated with Claude Code