Repository navigation
fix(route): sync bot public key before requests - #6726
SeniorZhai wants to merge 4 commits into
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: dbfd47850e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| defaultErrorHandle(MixinResponse<T>(requireNotNull(sessionResponse.error))) | ||
| endBlock?.invoke() | ||
| return null |
There was a problem hiding this comment.
When the key is absent after a fresh install or account switch and fetchSessionsSuspend returns an API error, this branch calls only defaultErrorHandle and returns without notifying failureBlock or exceptionBlock. For example, FetchWalletViewModel.importWallet enters IMPORTING at line 524 and only transitions to IMPORT_ERROR in those callbacks at lines 612–623; because it supplies no endBlock, the import UI remains stuck loading after this failure. Provide a dedicated session-sync failure callback or otherwise notify callers without treating a session 404 as a wallet 404.
Useful? React with 👍 / 👎.
| val publicKey = sessionResponse.data?.firstOrNull { it.userId == ROUTE_BOT_USER_ID }?.publicKey | ||
| check(!publicKey.isNullOrBlank()) { "Route bot public key is missing" } | ||
| preferences.putString(PREF_ROUTE_BOT_PK, publicKey) |
There was a problem hiding this comment.
This stores the newly fetched key only in preferences, unlike the existing authentication-retry path, which also updates ParticipantSession. After switching back to an account, preferences are cleared while that account's database is retained; if the database contains a pre-rotation route key, this preflight can fetch the current key but leave the stale database row intact. A later UserRepository.getBotPublicKey(..., false) reads that row and overwrites the current preference, and RefreshDappJob does exactly that before its direct route request; its 401 branch refreshes the key but does not retry the failed dapp fetch. Save the returned session alongside the preference so the database cannot restore a superseded key.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e35f068004
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| ): String { | ||
| var owner = false | ||
| val result = mutex.withLock { | ||
| pending ?: CompletableDeferred<String>().also { |
There was a problem hiding this comment.
When a normal get(force = false) is still reading a stale cached key as a 401 handler calls get(force = true), the forced caller receives the existing deferred and never invokes requestSession. requestRouteAPI then consumes its only retry using the same stale key and returns another authentication failure. Track whether the pending operation is forced, or wait for a non-forced operation to finish before starting the required refresh.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 6c75c61711
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| withContext(NonCancellable) { | ||
| mutex.withLock { | ||
| pending = null | ||
| outcome.fold(result::complete, result::completeExceptionally) |
There was a problem hiding this comment.
When the coroutine that created pending is cancelled while fetching the session, its CancellationException is stored in the shared deferred here. Every independent caller already awaiting that deferred then receives the same cancellation; for example, cancelling a fragment request can abort a background route refresh that merely happened to overlap it. Do not propagate an owner's cancellation through the shared result—run the load in an independent scope or let waiting callers retry synchronization after the owner is cancelled.
Useful? React with 👍 / 👎.
1 participant
No description provided.