feat: re-apply dual send for transport v2 (Phase B) without Riverpod 3.x#629
feat: re-apply dual send for transport v2 (Phase B) without Riverpod 3.x#629grunch wants to merge 6 commits into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. 🗂️ Base branches to auto review (1)
Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![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: b82dd4e278
ℹ️ 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".
| } | ||
| final wrappedEvent = await mostroMessage.wrap( | ||
| final wrappedEvent = await mostroMessage.wrapForTransport( | ||
| protocolVersion: mostroInstance?.protocolVersion, |
There was a problem hiding this comment.
When restore starts before the kind-38385 info event has populated mostroInstance, this passes null into wrapForTransport, which resolves to the v1 gift-wrap path. The subscription above already accounts for this race by listening on both transports, but the outbound restore request still goes out only as kind 1059, so a protocol-v2-only node never sees it and the restore times out. Please wait for the node protocol info or dual-send restore requests while the protocol is unknown.
Useful? React with 👍 / 👎.
…ests - Add _waitForNodeConnectivity to ensure the app is connected to the selected node before restore - Engage bootstrap relays immediately and wait for kind 38385 info event to prove connectivity - Fall back to best-effort attempt if info event not received within discovery window - Add _initRetryTimer to OpenOrdersRepository to poll for NostrService readiness - Defer order subscription until NostrService.isInitialized to avoid
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
fix: resolve provider init and node-switch restore connectivity races
* feat(transport): implement protocol v2 (NIP-44 direct) send path with identity proof (Phase B) * feat(transport): route all outbound Mostro sends through wrapForTransport (Phase B) * feat(restore): add dual-receive support for transport v2 (NIP-44 direct) in restore flow * test(restore): add dual-receive transport v2 regression tests for restore flow * fix(transport): bind dispute identity proof and guard restore tuple - DisputeRepository.createDispute now passes masterKey/keyIndex to wrapForTransport so reputation-mode disputes carry the v2 identity proof instead of being silently downgraded to full-privacy, matching publishOrder. - decodeRestoreMessage guards against an empty JSON tuple before indexing [0] to avoid a RangeError. - Refresh stale NIP-59-only comments in the dispute send path. --------- Co-authored-by: grunch <fjcalderon@gmail.com>
AndreaDiazCorreia
force-pushed
the
feat/transport-v2-phase-b-reapply
branch
from
b82dd4e to
90723bd
Compare
…ion reset - Add RestoreService.isOperationInProgress and awaitOperationCompletion() to expose restore/sync state - AddOrderNotifier.submitOrder now waits for any in-flight restore to finish before creating an order - Prevents session orphaning when node-switch restore's _clearAll wipes sessions mid-order-creation
|
This PR has been closed and #632 has been opened in its place. |
2 participants
Summary
Re-applies the content of #624 (dual send for transport v2, Phase B) on top of the rollback, without any Riverpod 3.x changes from #613.
This is a clean cherry-pick of the original #624 commit onto the reverted (Riverpod 2.6.1) base. The diff is byte-identical to the original #624 delta and contains no Riverpod 3.x API usage (only
ref.read(settingsProvider), which is identical in Riverpod 2.x and 3.x).Contents
mostro_message.dart,mostro_service.dart)Dependency
revert/riverpod-3x-rollback(revert: roll back Riverpod 3.x migration (#613) and dependent PRs (#624, #625) #628). Merge revert: roll back Riverpod 3.x migration (#613) and dependent PRs (#624, #625) #628 first. GitHub will retarget this PR tomainautomatically once revert: roll back Riverpod 3.x migration (#613) and dependent PRs (#624, #625) #628 merges.Original author: Andrea Diaz (preserved via cherry-pick).