feat: bundle ID migration + gitea#2 task-cache fix (recovered from fix/task-cache-unification) #4
Reference in New Issue
Block a user
Delete Branch "feat/bundle-id-and-task-cache"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Summary
Recovers 13 commits that were stranded on
fix/task-cache-unificationafter therc/android-ios-parityPR landed on master. Cherry-picked onto current master with conflicts resolved to preserve both the parity-gallery refactor (master's reactive-projection pattern,IDataManagerinterface,dataManagerinjection) AND the task-cache unification work (single source of truth from_allTasksfiltered by residence).What's included
Bucket B — Critical infra
ef8eab4iOS bundle ID + team ID migrationcom.tt.honeyDue.*→com.myhoneydue.honeyDue.*, teamV3PF3M6B6U→X86BR9WTLD. Required for current TestFlight signing + APNs (matches the api'sAPNS_TOPIC=com.myhoneydue.honeyDueandapns_team_id=X86BR9WTLD). This is what was missing when the bundle ID showed up wrong.Bucket C — gitea#2 fix: "tasks created during onboarding don't appear until app restart"
12 commits, in dependency order:
65803a2plan doc87771efaccessibility identifiers (test scaffolding)733d4c8failing test5f7498bfix:DataManager.updateTaskseeds_allTaskswhen cache is empty ← the actual root cause fix3df5645test lock-down4f9b910fix:bulkCreateTasksforce-refreshes_allTasks915a5d4test: characterizegetTasksForResidencefilter contractdea8eedrefactor:getTasksByResidenceis a thin filter over_allTasks882801ciOS:TaskViewModelobserves$allTasksand filters by residence in-memory1884853Android:ResidenceViewModel.residenceTasksStatederives from_allTasks03a9dfafix: 2 latent iOS bugs that blocked Suite11 XCUITestBuild infra
b90533cbuild: bump Gradle daemon to 6G + Kotlin daemon to 4G withMaxMetaspaceSize=1gand G1GC. Fixes the OOM duringComposeApp.frameworkgeneration.What's NOT included
cec521b refactor: delete _tasksByResidence and per-residence task cache plumbingwas skipped. Removing the property cascades to:IDataManager.ktinterface (added by parity-gallery, declarestasksByResidence)DataManagerObservable.swiftmirrorDoing the cascade safely is a separate, larger refactor against the parity-gallery interface. The practical effect of the skip:
_tasksByResidencestays as dead code on the DataManager — nothing reads from it anymore (verified by grep),ResidenceViewModel.ktwas modified inline to deriveresidenceTasksStatefromDataManager.allTasksfiltered (matchingcec521b's intent without removing the field).Conflicts resolved
iosApp/iosApp/Task/TaskViewModel.swiftinit(dataManager:)DI vs Bucket C's single-$allTaskssubscriptioninit(dataManager:)); merged to single subscription that filters by residence in-memory; dropped the second$tasksByResidencesubscriptioncomposeApp/.../viewmodel/ResidenceViewModel.kt_selectedResidenceIdreactive projection fromtasksByResidencevs Bucket C's_currentResidenceIdfrom_allTasks_selectedResidenceIdand the_deleteResidenceStatefield; modified the existingresidenceTasksState = combine(_selectedResidenceId, dataManager.tasksByResidence)tocombine(_selectedResidenceId, DataManager.allTasks)filtered viagetTasksForResidence(id)iosApp/HoneyDueUITests/Suite11_TaskCacheRegressionTests.swiftcec521b, modified in03a9dfaVerification
compileDebugKotlinAndroid— BUILD SUCCESSFULcompileKotlinIosArm64— BUILD SUCCESSFULxcodebuild -scheme HoneyDue— BUILD SUCCEEDEDSuite11 XCUITest hasn't been re-run on this branch yet — recommend running it before merge to confirm gitea#2 still doesn't reproduce. The two regression scenarios:
Branch provenance
Once merged,
fix/task-cache-unificationcan be deleted — its remaining commits (cec521b, plus the two upload commits already on master via PR #3) are either obsolete or already shipped.Captures gitea#2 at the cache layer. Three tests: - updateTask_seedsAllTasks_whenCacheIsEmpty (the core bug) - updateTask_distributesAcrossColumns_whenSeedingThenAdding - updateTask_replacesExistingTaskById_acrossColumns All three FAIL on this commit because updateTask is a conditional ?.let{} that no-ops when _allTasks is null. Phase 1 fix in the next commit makes them green.