Repository navigation
Journal import: recognize the real WHOOP "Answered yes" header (#631) - #706
Merged
ryanbr merged 1 commit intoJul 22, 2026
Merged
Conversation
…r#631) Both the Android and Swift CSV journal importers looked up the answer column only as answered_yes_no / answer / answer_text. That matches NOOP's own exporter (which writes "Answered yes/no"), but a real WHOOP export names the column "Answered yes" -> answered_yes, which never matched. Every imported journal answer silently read false ("Without" in Insights), regardless of what the account actually answered - confirmed against a reporter's real journal_entries.csv (300+ days, every answer zeroed out, native logging correct). Fix: add answered_yes as a (first) candidate key on both platforms. Added a regression test on each side using the real header and TRUE/FALSE casing from the reporter's export. Does not fully close ryanbr#631 by itself if the reporter's export also has other quirks, but fixes the confirmed root cause. Doesn't touch ryanbr#682 (the separate never-asked-vs-no partition fix already split out from this issue).
digitalerdude
marked this pull request as ready for review
July 21, 2026 14:56
DX23876
pushed a commit
to DX23876/noop
that referenced
this pull request
Jul 22, 2026
…rt-answered-yes-header Journal import: recognize the real WHOOP "Answered yes" header (ryanbr#631)
simoncad7
pushed a commit
to simoncad7/noop
that referenced
this pull request
Aug 17, 2026
…rt-answered-yes-header Journal import: recognize the real WHOOP "Answered yes" header (ryanbr#631)
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.
Addresses the confirmed root cause of #631, using the reporter's real
journal_entries.csv(attached in the issue thread).Root cause
Both the Android (
WhoopCsvImporter.parseJournal) and Swift (WhoopExportImporter.parseJournal) importers looked up the answer column only viaanswered_yes_no/answer/answer_text(normalized keys). That matches NOOP's own exporter, which writes the headerAnswered yes/no— but a real WHOOP export names the columnAnswered yes(no/no), which normalizes toanswered_yesand never matched any of the old candidates.Confirmed directly against the reporter's actual file:
So
answerwas alwaysnullon a real import,parseYesNo/(j.answer ?? "").lowercased() == "true"always fell through tofalse, and every single day imported as "Without" in Insights — matching the reporter's account exactly (answered directly for 300+ days, every one zeroed out, while native/live-logged entries were correct).This also rules out the with/without-partition theory from the earlier discussion (that's the separate #682 fix, which doesn't touch this).
Fix
Added
answered_yesas the first candidate key on both platforms:android/app/src/main/java/com/noop/ingest/WhoopCsvImporter.ktPackages/StrandImport/Sources/StrandImport/WhoopExportImporter.swiftTesting
TRUE/FALSEcasing from the reporter's real export:WhoopCsvImporterTest.importedJournalReadsRealWhoopAnsweredYesHeaderWhoopExportImporterTests.testJournalReadsRealWhoopAnsweredYesHeaderswift test(Packages/StrandImport): 208 tests, 0 failures ✓./gradlew compileFullDebugKotlin testFullDebugUnitTest --tests "com.noop.ingest.*"✓ (JDK 17 via Homebrew;android.yml/app-build are disabled so this is local-only for now)Scope note
This fixes the confirmed root cause (the header mismatch) but I haven't independently verified it resolves every last row of the reporter's specific export end-to-end — if their file turns out to have an additional quirk beyond this, that would need its own follow-up. Doesn't close #682.