Re-freeze with the NaN fix, re-test the custom-meal path, and settle the scanner #1262

Activity

1. simonoppowa

   added

   wayfinder:task

   on Sep 25, 2026
2. simonoppowa

   added a parent issue on Sep 25, 2026

   • Map: a verified go/no-go for 2.4.0 — every feature area on the Pixel 6 before develop meets main #1232
3. github-project-automation

   added this to OpenNutriTracker Roadmapon Sep 25, 2026
4. github-project-automation

   moved this to Todo in OpenNutriTracker Roadmapon Sep 25, 2026
5. simonoppowa commented on Sep 26, 2026

   

   simonoppowa

   on Sep 26, 2026

   OwnerAuthor

   More actions

   Re-freeze done, the device is clean, and the scanner is settled. One item accepted on unit coverage rather than device evidence — stated plainly below.

   What landed

   Step	Result
   Merge #1259, #1261; bump	All on develop: c55a2ccf (NaN fix), 780a7124 (store notes), 680eafaa (2.4.0+66).
   Re-freeze and rebuild	Candidate is 680eafaa; ont-refreeze-680eafaa-full-debug.apk reports versionCode='66' versionName='2.4.0'.
   Upgrade in place	Installed over the existing install: firstInstallTime still 2026-09-19, so a true upgrade. The whole fixture survived — four Open Food Facts intakes, both recipes, seven weight entries, the activity.
   Both startup repairs	Correct, and their silence is the point. No OffMicronutrientRepair line — the rows are already stamped, so it is the no-op the design promises. No TrackedDayTotalRepair line either: ensureTrackedDayTotalsFinite returns at if (broken.isEmpty) return 0; before logging, and nothing on this device was ever NaN. Zero E/flutter, zero FATAL, zero Infinity or NaN toInt across the session.
   Migration still intact	Confirmed durable across a second upgrade.
   Export scan	Every field of user_intake.json, user_tracked_day.json, user_recipes.json and user_activity.json walked recursively: zero non-finite values, and zero literal NaN/Infinity in the JSON text.
   Scanner (the last inconclusive item)	Pass — maintainer confirmed the camera image appears. The black preview in the previous run was the dark room, not mobile_scanner 7.4.1.

   The one thing not verified on device, and why that is acceptable

   The zero-base-quantity path itself was not exercised. custommealbox.hive is 0 bytes and every intake in the export is source: off — no custom meal was created, so the 100 / 0 → NaN → broken-totals sequence never ran. The screens rendering proves the build is healthy; it does not prove #1259 fixes #1254.

   Accepted on unit coverage, which reproduces the reported case by name rather than by inference:

   group('factorTo100gFromBase with a zero base (#1254)')
     '"0" falls back to a no-op factor of 1 instead of infinity'   → expect(…('0'), 1.0)
     'a negative base falls back to 1'
     'a nutriment typed as 0 at a zero base stays 0, not NaN'
         // The reported custom meal: every field 0, base quantity included.
   

   plus eight tests on tracked_day_total_repair (rebuilds a NaN day from its intakes, honours the day-start boundary, leaves finite days alone, rebuilds a broken day with no intakes to zero) and entity-level non-finite handling. All green on the merge run.

   The honest statement for the release: #1259 is verified by targeted unit tests that reproduce the reported scenario, and the rebuilt candidate is verified clean on device; the two were not joined up by logging a zero-base custom meal on the phone. The blocker for that is known and recorded — the custom-food form exposes no field identifiers and its keyboard reshuffles positions between taps, which is why S4 blocked in the first run too. The same form is both the bug's home and the reason it is hard to test, and that is worth fixing before the next release rather than during this one.

   Candidate for the develop → main PR: 680eafaa.
6. simonoppowa

   closed this as completedon Sep 26, 2026