fix: SoftAP/BLE device provisioning navigation & retry fixes (PROD-5897/5940/6041/6042) - #2
Open
deaflynx wants to merge 8 commits into
Open
fix: SoftAP/BLE device provisioning navigation & retry fixes (PROD-5897/5940/6041/6042)#2deaflynx wants to merge 8 commits into
deaflynx wants to merge 8 commits into
Conversation
…D-6041) The "Device not able to find Wi-Fi nearby" screen passed an empty onTryAgain callback, so its Try again button did nothing. Wire it to EspSoftApConnectToDeviceEvent so it reconnects and re-scans for networks, matching the "Unable connect to device" error screen. (cherry picked from commit 0fad5d6136a5bdceaeb2599d3c960ed897a418d0)
…text TbContext is no longer registered in GetIt (commented out in locator), so getIt<TbContext>() in the device provisioning action threw and broke the entire provisioning flow before it started. Read the current user's authority via ITbClientService().client.getAuthUser() to gate the customer-role check, matching how the rest of the app reads the user. (cherry picked from commit ccf31760ba044f181b3ce6cbad5550b9fce2e8cb)
…works (PROD-5897)
On Android, connectToSecureNetwork binds the whole process to the home
Wi-Fi network (bindProcessToNetwork) so the device can be claimed over
the internet. That binding was never released, so a later provisioning
attempt could no longer reach the device SoftAP at 192.168.4.1 ("Machine
is not on the network", errno 64) and showed "Unable connect to device"
on re-entry after a failed claim.
Release the binding via PluginWifiConnect.disconnect() once claiming
resolves (success or failure) in DeviceProvisioningBloc, and as a safety
net in EspSoftApView.dispose() for early exits.
(cherry picked from commit 011193693e7fcfb4576a3d1d4c9894bbc826e0a5)
…pdates immediately (PROD-5940) Tapping Ready / Try again while a previous connection-retry chain was still cycling spawned a second concurrent chain that shared the connectionRetries counter and kept emitting states, so a stale chain could repaint the "Unable connect to device" screen right after the user's new action. Tag each connection attempt with a monotonic generation: a user-initiated tap bumps it and resets the retry budget, while internal retries carry their own generation and bail at every suspension point once superseded. The latest user action now always wins and the loading state shows immediately. (cherry picked from commit c4b91f16a2ea868eff2486f2e7171be061930e5d)
… screen (PROD-6042) Tapping Ready without joining the device's Wi-Fi previously sat on a bare spinner for ~90s (6 x 15s retries) and then showed a generic error. - Loading screen now shows the in-progress attempt number instead of a silent spinner. - Retries are tuned per platform: iOS keeps a short exponential backoff (1/2/4/8s) to ride out the one-time Local Network permission prompt; Android, which has no such prompt, retries once and fails fast. - The connection-error screen now explains the likely cause (phone not on the device's Wi-Fi) and offers an Open Wi-Fi settings button; the Wi-Fi-not-found copy is clearer too. (cherry picked from commit 7a30d1cbd92813b2adc4b365960db5b3b69e83b4)
EspSoftApBloc.close() unconditionally called provisioning.dispose(), but provisioning is a late field only assigned after a successful startProvisioning. Exiting the flow after a failed connection (e.g. the device's Wi-Fi was never joined) therefore threw a LateInitializationError. Track initialization with a flag and only dispose when set. Found while testing PROD-6042. (cherry picked from commit 7586f82bf33a53993b7973fa8e6dea8a4887c2b0)
The exit confirmation dialog's 'Yes' action popped the navigator twice
unconditionally: once to close the dialog and once to leave the
provisioning page. When the provisioning page was the only remaining
route, the second pop emptied the stack and crashed GoRouter
('popped the last page off of the stack'), leaving a dark screen.
The dialog now returns a bool result; each caller (SoftAP and BLE
views) awaits it and pops the page once via maybePop(), guarded by
context.mounted.
(cherry picked from commit 2088dacbaf3e3fada0aed95e49a920366780f784)
MobileScanner.onDetect fires per camera frame, so the QR route was popped multiple times: the first pop returned the Barcode correctly, but a lingering second pop popped the next route (the ESP provisioning page) with a stray Barcode result. On re-scan after a failed claim this flashed the SoftAP page (onCreate->onClose) and, via navigateTo's blind 'result as T?', crashed with a TypeError. - qr_code_scanner: one-shot guard so onDetect pops exactly once - router: navigateTo returns null on an unexpected result type instead of throwing (cherry picked from commit fdfa1091a8ab2615d3f9d25224b4610a9fffc926)
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
1 participant
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.
Summary
Ports the SoftAP/BLE device-provisioning navigation, retry, and error-handling fixes onto the new-dart-client branch. These were validated end-to-end on a real ESP32 (SoftAP) device.
Cherry-picked as 8 focused commits covering 5 reported issues:
Testing
Verified on physical ESP32 (SoftAP) on Android (Pixel 6, Android 16):
SuccessfullyProvisionedEvent).flutter analyzeon the touched code: no issues.Notes
intl_en.arbgained 3 strings; generated l10n regenerated viaintl_utils.🤖 Generated with Claude Code