Cleanup tracker for the post-merge work surfaced during PR #95 (the onboarding publish-failure banner from #88). Each item is independently scoped — feel free to split into separate issues if any of them gets prioritized; this issue is the catch-all so nothing falls off.
1. Manual iPhone 16e device verification of #95
The PR landed without on-device walkthrough — the device was locked every time during the session. Should walk:
- Cold-start onboarding with airplane mode on after ProfileSetup
- Tap Continue on ProfileSetup → confirm banner fires at ~60s
- Tap Retry while still offline → banner re-arms, doesn't fire while offline
- Disable airplane mode → banner self-dismisses once publish clears
- Repeat on PaymentSetup, confirming
settingsBackup copy
- Verify banner placement looks right with notch / Dynamic Island (the
1e2de05 Color.rfSurface.ignoresSafeArea() background fix)
Could ride along with the next TestFlight build if device verification keeps slipping.
2. SDK error surface for publishProfileAndMark
RoadflareDomainService.publishProfileAndMark (and publishAndMark on ProfileBackupCoordinator) currently swallow errors silently — they log failure but return Void regardless. The watchdog in #95 observes the dirty flag as a proxy for failure, which means the banner only fires after the 60s timeout even when the relay returned a clear error.
Surfacing the error directly would let the banner fire as soon as the publish fails, with a more accurate copy ("the relay rejected your publish" vs "we couldn't reach the relay"). Behind a real SDK API change (existing call-sites would need to handle the propagated error type, similar to the requestKeyRefresh throws migration in ADR-0013).
3. Top-bar offline indicator (orthogonal to publish-failure banner)
The repo has ConnectivityIndicator.swift (a full-screen reconnect view) but it has zero callers. Per-tab views (DriversTab, HistoryTab, RideTab) each check isRelayConnected() independently and render their own inline offline UI.
A global "you're offline" pill — pinned somewhere consistent across the app — would:
- Contextualize the publish-failure banner ("of course your publish hasn't landed; your connection is also down")
- Let the user spot connectivity issues without checking specific tabs
- Replace or rehome the dead
ConnectivityIndicator view
Design questions: where does the pill live? Top of RootView (above the publish-failure banner)? Toolbar item on each tab's NavigationStack? Should tapping show diagnostics?
4. Banner persistence across kill+relaunch
Currently OnboardingPublishStatus resets to .idle on cold launch even if the dirty flag persists in RoadflareSyncStateStore. ADR-0015 Consequences §"Watchdog lifetime" calls this an accepted trade-off — the setupServicesWithSync startup-sync flow runs reconnect-flush which would re-publish dirty domains and clear them naturally.
If real-device testing reveals the silent retry isn't reliable (e.g. user remains in a relay dead zone across multiple launches), surface the banner on cold launch when domains are dirty rather than waiting for the user to manually trigger a retry. Latent — depends on what device verification (item 1) finds.
Priority
All lower than the App Store submission timeline. #1 (device verification) is most time-sensitive — gates the confidence in #95's UX. #2 (SDK error surface) is the most architectural and would benefit from its own ADR. #3 (offline indicator) is its own UX feature. #4 (banner persistence) is conditional on #1's findings.
🤖 Generated with Claude Code
Cleanup tracker for the post-merge work surfaced during PR #95 (the onboarding publish-failure banner from #88). Each item is independently scoped — feel free to split into separate issues if any of them gets prioritized; this issue is the catch-all so nothing falls off.
1. Manual iPhone 16e device verification of #95
The PR landed without on-device walkthrough — the device was locked every time during the session. Should walk:
settingsBackupcopy1e2de05Color.rfSurface.ignoresSafeArea()background fix)Could ride along with the next TestFlight build if device verification keeps slipping.
2. SDK error surface for
publishProfileAndMarkRoadflareDomainService.publishProfileAndMark(andpublishAndMarkonProfileBackupCoordinator) currently swallow errors silently — they log failure but returnVoidregardless. The watchdog in #95 observes the dirty flag as a proxy for failure, which means the banner only fires after the 60s timeout even when the relay returned a clear error.Surfacing the error directly would let the banner fire as soon as the publish fails, with a more accurate copy ("the relay rejected your publish" vs "we couldn't reach the relay"). Behind a real SDK API change (existing call-sites would need to handle the propagated error type, similar to the
requestKeyRefreshthrowsmigration in ADR-0013).3. Top-bar offline indicator (orthogonal to publish-failure banner)
The repo has
ConnectivityIndicator.swift(a full-screen reconnect view) but it has zero callers. Per-tab views (DriversTab,HistoryTab,RideTab) each checkisRelayConnected()independently and render their own inline offline UI.A global "you're offline" pill — pinned somewhere consistent across the app — would:
ConnectivityIndicatorviewDesign questions: where does the pill live? Top of
RootView(above the publish-failure banner)? Toolbar item on each tab's NavigationStack? Should tapping show diagnostics?4. Banner persistence across kill+relaunch
Currently
OnboardingPublishStatusresets to.idleon cold launch even if the dirty flag persists inRoadflareSyncStateStore. ADR-0015 Consequences §"Watchdog lifetime" calls this an accepted trade-off — thesetupServicesWithSyncstartup-sync flow runs reconnect-flush which would re-publish dirty domains and clear them naturally.If real-device testing reveals the silent retry isn't reliable (e.g. user remains in a relay dead zone across multiple launches), surface the banner on cold launch when domains are dirty rather than waiting for the user to manually trigger a retry. Latent — depends on what device verification (item 1) finds.
Priority
All lower than the App Store submission timeline. #1 (device verification) is most time-sensitive — gates the confidence in #95's UX. #2 (SDK error surface) is the most architectural and would benefit from its own ADR. #3 (offline indicator) is its own UX feature. #4 (banner persistence) is conditional on #1's findings.
🤖 Generated with Claude Code