Context
Found while testing #669, which adds a shareable mostro: link to the order detail. The crash is not caused by that branch — see the verification below.
Opening a valid mostro: deep link while the app is not in the foreground crashes it:
'package:go_router/src/match.dart': Failed assertion: line 245 pos 12:
'uriPathToCompare.startsWith(newMatchedLocationToCompare)': is not true.
Reproduction
On a debug build (Android 16, Nothing Phone 3a):
- Open the app and let the order book load.
- Tap any order to open its detail screen.
- Press Back until the app leaves the foreground.
- Open a
mostro: link for a real order:
adb shell 'am start -a android.intent.action.VIEW -d "mostro:<order-id>?relays=wss://mostro-p2p.tech,wss://nos.lol,wss://relay.mostro.network&mostro=82fa8cb978b43c79b2156585bac2c011176a21d2aead6d9f7c575c005be88390"'
The app comes up on the red assertion screen instead of the order.
The link itself is fine and reaches the app intact — logcat shows the full URI arriving and being processed:
D com.llfbandit.app_links: Handled intent: action: android.intent.action.VIEW / data: mostro:<order-id>?relays=...&mostro=...
I flutter : 💡 Processing mostro link: mostro:<order-id>?relays=...&mostro=...
I flutter : #0 DeepLinkService.navigateToOrder (package:mostro_mobile/services/deep_link_service.dart:250:12)
The same link opened while the app is already in the foreground works correctly and navigates to the order, repeatedly. Only the not-in-foreground path fails, which points at the navigation done from DeepLinkHandler.handleInitialDeepLink / DeepLinkService.navigateToOrder running against a router whose location is not what the assertion expects.
Not caused by #669
Verified by building and installing main at c3c2d7a7 with that branch checked out nowhere near it, then repeating steps 1-4: identical assertion, identical screen.
Why it matters
assert is stripped from release builds, so users would not see the red screen — but the navigation is just as broken, and the failure mode there is silent instead of loud.
This has been low-impact so far because almost nobody had a mostro: link to open. #669 puts one behind a copy button on every takeable order, so links are about to become common: someone pastes one into Telegram, the recipient taps it while the app is backgrounded, and this is what they get.
Context
Found while testing #669, which adds a shareable
mostro:link to the order detail. The crash is not caused by that branch — see the verification below.Opening a valid
mostro:deep link while the app is not in the foreground crashes it:Reproduction
On a debug build (Android 16, Nothing Phone 3a):
mostro:link for a real order:The app comes up on the red assertion screen instead of the order.
The link itself is fine and reaches the app intact —
logcatshows the full URI arriving and being processed:The same link opened while the app is already in the foreground works correctly and navigates to the order, repeatedly. Only the not-in-foreground path fails, which points at the navigation done from
DeepLinkHandler.handleInitialDeepLink/DeepLinkService.navigateToOrderrunning against a router whose location is not what the assertion expects.Not caused by #669
Verified by building and installing
mainatc3c2d7a7with that branch checked out nowhere near it, then repeating steps 1-4: identical assertion, identical screen.Why it matters
assertis stripped from release builds, so users would not see the red screen — but the navigation is just as broken, and the failure mode there is silent instead of loud.This has been low-impact so far because almost nobody had a
mostro:link to open. #669 puts one behind a copy button on every takeable order, so links are about to become common: someone pastes one into Telegram, the recipient taps it while the app is backgrounded, and this is what they get.