chore: synchronize packages dependency versions#1
Merged
Conversation
shumkov
changed the title
added 2 commits
November 3, 2021 18:13
# Conflicts: # packages/js-dash-sdk/package-lock.json # packages/js-dash-sdk/package.json # packages/js-dpp/package-lock.json # packages/js-dpp/package.json
# Conflicts: # packages/wallet-lib/package.json
antouhou
changed the title
antouhou
marked this pull request as ready for review
November 4, 2021 10:49
# Conflicts: # packages/dashmate/package.json
jawid-h
added a commit
that referenced
this pull request
Dec 27, 2021
jawid-h
added a commit
that referenced
this pull request
Dec 27, 2021
This was referenced May 29, 2026
This was referenced Jun 5, 2026
Merged
Merged
6 tasks
shumkov
added a commit
that referenced
this pull request
Jun 15, 2026
…, contactInfo index allocation (review P0s/Critical) Multi-reviewer pass found three serious bugs in the M3 rotation code that the live UAT missed (UAT only exercised the pending-sent rotation path, which the reject-tombstone masked). All fixed with red→green regression tests. P0 #1 — rotation re-send to an ESTABLISHED contact reset the version to 0. The version bump unmasked the prior sent request's accountReference, but the lookup only consulted `sent_contact_requests` — empty once established (the outgoing request moves into `established_contacts.outgoing_request`). So every real re-key read None, reset version to 0, reproduced the original reference, and was rejected by the contract's `(ownerId, toUserId, accountReference)` unique index. New `ManagedIdentity::prior_sent_account_reference` checks both maps. Test: prior_sent_account_reference_falls_back_to_established_outgoing. P0 #2 — multi-doc sweep thrash. Immutable contactRequest docs are never deleted, so after any accepted rotation a sender has two non-tombstoned docs that BOTH return every sweep. The per-doc dedup compared each against a single tracked reference, so the other doc always triggered apply_rotated — flipping stored state 0↔7, tearing down + rebuilding the external account, and writing changesets every 60s forever. New `newest_received_per_sender` collapses to the newest doc per sender before ingest (a sweep fixpoint); apply_rotated also gains an identical-request idempotency guard. Tests: newest_received_per_sender_collapses_rotated_sender_to_latest_doc, apply_rotated_incoming_request_is_idempotent. Critical (C1) — swallowed persist errors → memory/disk divergence. ~8 state methods mutated in-memory then only logged a store() failure. Worst case: reject() returned Ok even when the tombstone didn't persist → the rejected contact resurrects on next launch with no signal. New PlatformWalletError::Persistence; reject_contact_request and the user-initiated send_payment path now PROPAGATE the error (self-healing sweep writes still log — the immutable on-chain doc / UTXO reconcile re-derives them). Test: reject_propagates_persist_failure (toggle-fail persister, RED→GREEN). Plus: - #6: send-path encryptedPublicKey extraction returns a hard Err instead of a release-no-op debug_assert + zero-fill (would persist a valid-looking all-zero ciphertext if SDK encoding drifts). - #7: contactInfo derivation-index allocated from a high-water mark over ALL owned docs (incl. skipped/undecryptable), not just the decryptable subset — a skipped doc's slot would otherwise collide on the unique index. - #5 (Rust half): set_contact_info returns a 3-state ContactInfoPublishOutcome (Published / DeferredUntilTwoContacts / SkippedWatchOnly) so the UI can stop claiming an unconditional sync. - crypto LOW: documented the account_index/accountReference consistency invariant at the send boundary. 230/230 platform-wallet lib tests green.
This was referenced Jun 15, 2026
feat(swift-example-app): wallet-signed Transfer & Withdraw for platform addresses (ADDR-02/04)
#3923
Merged
6 tasks
shumkov
added a commit
that referenced
this pull request
Jun 23, 2026
…s unavailable (no channel-kill) Phase-2 prerequisite (seed-elimination spec section 4.7). The unattended background sync sweep (build_contact_accounts) could irreversibly kill a contact's payment channel over a *recoverable* condition: - The is_seedless gate keyed on identity_index.is_none(), which a wallet-owned but seedless (watch-only) identity passes (it HAS an index) — so it fell through to step 1 (receiving account) churning every sweep and step 3 (ECDH external account) classifying the derive failure as Permanent -> mark_contact_channel_broken. A locked Keychain / not-yet-attached seed thus permanently disabled payments to a contact. Fix - a three-state classification (audit must-fixes #1 + #3): - RegisterExternalError gains a third arm Unavailable (!= Transient != Permanent) + is_unavailable(): key material absent right now -> DEFER, never break, never churn. - register_external_contact_account checks wallet.has_seed() before the ECDH derive and returns Unavailable when seedless (was: derive failure -> Permanent). - build_contact_accounts gates on has_seed() (BuildReadiness NotOurs / KeyMaterialUnavailable / Ready) instead of identity_index.is_none(), so a seedless wallet-owned identity defers (no step-1 churn, no step-3 kill); step 3 also handles Unavailable defensively (gate/derive race). Currently 'can derive' == has_seed(); the seedless model extends this to an available resolver-backed signer. The deferral logs + pauses; the persisted pending-crypto queue + UI 'needs unlock' marker land with spec section 4.6. TDD: register_external_classifies_seedless_wallet_as_unavailable would have caught this in CI - before fix it got Permanent("Our encryption key 0 not found") (the missing-key check fired ahead of any seed check); after fix it gets Unavailable. The two existing classification tests (transient infra-miss, permanent missing-key) stay green. 295/295 lib tests, clippy clean, downstream FFI compiles. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
shumkov
added a commit
that referenced
this pull request
Jun 23, 2026
…orrect discovery over-scope Spec gains a Q2 status+completion-criteria banner: #1-6 (contact-request flow) done; remaining = #7 contactInfo + discovery ResidentWallet-fallback removal + Swift drain-on-unlock + delete attach_wallet_seed; done-when = git grep empty + builds + testnet on-device acceptance. Corrects the prior over-scoping of discovery: the carry-scalar fix is KEPT (per spec §1/§2/§7), not a rewrite target. TODO gains the Q2 checklist + the out-of-Q2 findings: §6b queue restore (upstream-blocked), §4.2 wipe hardening, §4.8 zero-keys import caveat. auto_accept already tracked separately. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
57 tasks
shumkov
added a commit
that referenced
this pull request
Jul 14, 2026
…st proof assembly Second-pass review fixes on #4041. #1 (blocking): persist the invitation record immediately after funding, BEFORE the InstantSend check — a ChainLock-confirmed voucher is rejected as a *link* but is still a funded, reclaimable lock, so it must be recorded rather than orphaned. My earlier fix put the persist after the IS/CL check, which still orphaned it. #2 (blocking): claim-by-fetch now retries the funding-tx lookup (both byte orders) with a bounded backoff (5 x 3s). InstantSend/ChainLock finality doesn't guarantee the invitee's DAPI node has indexed the tx, so a freshly shared invitation could fail on ordinary propagation lag with no retry. #5: extract the post-fetch proof reconstruction into a pure `assemble_asset_lock_proof` and unit-test its guards (txid mismatch, chainlock-required, chainlock-success, islock-locks-wrong-tx) — previously zero coverage on funds-adjacent logic. #6: `encode_invitation_uri` now rejects a final URI over `MAX_INVITATION_URI_LEN` (percent-encoding can expand fields past the per-field raw cap) — the exact length its own parser enforces, so it can't emit a self-unparseable link. #7: correct the preview FFI `inviter_username` doc — a null username no longer implies has_inviter==false (metadata-only links set has_inviter with a null username). invitation tests: 28/28 (+4 assemble_*) platform-wallet, 10/10 ffi. fmt + clippy clean. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
2 participants
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.
Issue being fixed or feature implemented
The build doesn't work because different packages use different versions of dependencies
What was done?
Synchronized dependency versions across all packages
How Has This Been Tested?
Run the build and run dashmate
Breaking Changes
None
Checklist:
For repository code-owners and collaborators only