fix(dashpay): preserve paid-action guards across identity switch and paginate contact info

[Claudius-Maginificent]

Why this PR exists

• Problem: Two DashPay defects remain open in ContactsState and create_or_update_contact_info. A paid-action double-submit guard is discarded whenever the user switches identity, wallet, or network — even while the guarded backend task is still running. Separately, the owner-scoped contactInfo lookup reads only the first page of results despite a comment claiming it reads all of them, so metadata selection is made against an incomplete set.

• What breaks without it:

  1. Paying twice for one action. Start a paid contact action (its backend task is still in flight) → switch identity, wallet, or network → reset_for_identity_change wipes every double-submit guard, including the live one → the action can be submitted again while the first is still running, and the user pays for it twice.
  2. Silent contact-data loss, or a duplicate document. An identity with 100+ established contacts has some contactInfo documents beyond the first page. Editing a contact whose record sits past that page → the lookup never sees the existing document → the code either writes a fresh one (duplicating that contact's record) or proceeds without the existing field values, silently dropping the contact's accepted-accounts allow-list, nickname, and note.

• Blocking relationship: Stacked atop fix: rebase SND-003 onto PR893 + QA-campaign fix batches #894, which was squash-merged into this base and carried the rest of this PR's original scope with it. Everything else previously described here — the wallet cold-boot lockout, migration-gate coverage, shielded chokepoint, DashPay preservation defaults, and the passphrase transition-frame fixes — is already merged and is no longer part of this PR. What remains is the single unmerged commit below.

What was done

• Preserve live guards across a context change — ContactsState::reset_for_identity_change keeps a paid-action guard whose backend task is genuinely still running, instead of wiping the whole guard set on an identity/wallet/network switch. View-only state still clears. Guards for abandoned confirmations are released, and timed-out entries are pruned, so nothing leaks and expired guards still self-heal.
• Paginate owner-scoped contactInfo — create_or_update_contact_info fetches every page before selecting update/create metadata, so the choice is made against the complete set rather than the first 100 documents.

Testing

Verification is running against the rebased tree; results will be posted here once complete. The pre-existing suite (cargo test --all-features --workspace, clippy --all-features --all-targets -D warnings, cargo +nightly fmt --all) is the gate, plus the contacts/dashpay tests covering guard lifecycle and pagination.

Breaking changes

None.

_{🤖 Co-authored by Claudius the Magnificent AI Agent}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

🗂️ Base branches to auto review (2)

• master
• v1.0-dev

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: dd3b08de-431e-42be-9664-cb1795ba6b97

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch integration/review-remediation

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[thepastaclaw]

⛔ Blockers found — Sonnet deferred (commit 2c69239)
Canonical validated blockers: 2

[thepastaclaw]

Preliminary review — Codex only

Three in-scope blocking issues remain at the exact head. Unsupported shielded tasks initialize wallet storage before their capability check, the migration gate loses DashPay request correlation, and newly activated passphrase prompts install their input barrier too late to prevent first-frame click-through.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 3 blocking

2 additional finding(s) omitted (not in diff).

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/backend_task/mod.rs`:
- [BLOCKING] src/backend_task/mod.rs:587-599: Reject unavailable shielded tasks before wallet initialization
  A dispatched `ShieldedTask` reaches `ensure_wallet_backend()` before `run_shielded_task()` checks `FeatureGate::ShieldedOperations`. On a cold context, initialization opens and hydrates wallet storage, then `bootstrap_loaded_wallets()` resolves every open wallet seed and can register wallets, bind Orchard keys, and register contact accounts. The capability is unavailable on every current protocol version, so unsupported requests can still cross the wallet and secret boundary or return a terminal storage-open error before the intended refusal. Check shielded availability before this generic initialization path.
- [BLOCKING] src/backend_task/mod.rs:607-613: Preserve DashPay request identity at the migration gate
  The migration gate returns a bare `WalletStorageNotReady` before `run_dashpay_task()` can attach the request ID for Accept, Reject, or Cancel. The legacy contact-request screen therefore cannot match the failure and leaves its request state and loading flag set. The Identity Hub instead clears every paid-action guard for this error, but backend tasks run concurrently and migration publishes `Running` asynchronously: request A can still be executing when request B is rejected by this gate, causing B's error to release A's guard and permit a duplicate paid submission. Wrap the gate error with the rejected DashPay action's request ID so each screen retires only that action.

In `src/app.rs`:
- [BLOCKING] src/app.rs:1752-1778: Install passphrase input barriers before rendering the screen
  When a queued secret prompt becomes active, `claim_overlay_input()` deliberately yields, the underlying screen processes the frame's input, and only afterward does `render_secret_prompt()` install the modal sink. Migration password prompts follow the same sequence because `is_prompting()` yields before `update_password_prompt()` renders at line 1801. In egui 0.35, `set_modal_layer()` records the modal for the current frame while widget interaction checks the modal layer carried from the previous frame, so a sink installed after an underlying button has returned `clicked()` cannot revoke that action. Preinstall the prompt's modal barrier before invoking the visible screen; the current kittest primes the modal for a frame before clicking and therefore does not cover this transition frame.

[Claudius-Maginificent]

@thepastaclaw both blocking findings from this review are fixed in 3e69b2fd (now on origin/integration/review-remediation @ 3591ea8c):

Shielded pre-check ordering (src/backend_task/mod.rs:587-599): run_backend_task now checks FeatureGate::ShieldedOperations::is_available() for any BackendTask::ShieldedTask as its very first statement, before the shared ensure_wallet_backend() bootstrap runs. Your read of bootstrap_loaded_wallets()'s reach (seed exposure, upstream registration, Orchard key binding, contact-account registration) was accurate — this makes the gate's own "before any wallet/backend access" claim literally true instead of aspirational.

DashPay gate request-identity scoping (src/backend_task/mod.rs:607-613, src/ui/identity/hub_screen.rs:576-587): added dashpay_request_id(&BackendTask) -> Option<Identifier>, matching AcceptContactRequest/RejectContactRequest/CancelContactRequest. The migration gate now wraps a rejected DashPay contact action in TaskError::DashPayContactRequestActionFailed { request_id, source } instead of returning a bare WalletStorageNotReady, and release_request_guard_for_error was narrowed to release only the matching request's guard — the old blanket WalletStorageNotReady => clear_in_flight() arm was deleted entirely (confirmed: zero remaining callers).

On severity: both independently re-derived as LOW, not Blocking:

• Shielded gate — risk 0.29 / impact 0.06 / scope 0.20. No shielded operation could actually execute (the in-handler gate still refused before any fund movement); UI shielded buttons are separately gated; reachable only via MCP/direct dispatch; seed material never left the sanctioned secret-seam chokepoint or the caller.
• DashPay guard — risk 0.21 / impact 0.07 / scope 0.20. The re-entry window is real, but all three contact actions re-check freshly-fetched Platform state before acting (not the clicked row), and DashPay contact-request documents carry a Platform-enforced uniqueness constraint — a re-dispatched action in the TOCTOU window gets a clean rejection or no-op, not a silent duplicate. Also a net narrowing of pre-existing base behavior (the prior blanket-clear already accepted "worst case: a re-enabled row" as its tradeoff).

Both fixes were independently mutation-tested (revert → RED with the exact regression symptom; restore → GREEN) by an agent that didn't write them, plus a full cargo test --all-features --workspace / clippy -D warnings / fmt --check gate. Full write-up in the PR description.

[thepastaclaw]

Thanks — I see the shielded and DashPay remediation in 3e69b2fd, plus the transition-frame production-wiring regression coverage at head 3591ea8c. I’ve prioritized an independent exact-head re-review, with this thread context included as evidence.

[thepastaclaw]

Preliminary review — Codex only

Current head fixes all three previously indexed blockers. Two in-scope DashPay blockers remain: identity switching can release a paid-action guard while its task is still running, and contact-info preservation examines only the first 100 documents. Diff and formatting checks passed; focused test execution remains unavailable because the required Tenderdash download was declined.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 2 blocking

1 additional finding(s) omitted (not in diff).

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/ui/state/contacts_view.rs`:
- [BLOCKING] src/ui/state/contacts_view.rs:97-100: Identity switching clears guards for paid actions that are still running
  `reset_for_identity_change()` clears every paid-action guard, but switching identity, wallet, or network does not cancel tasks already spawned by `AppState`. A user can start Accept, Decline, or Cancel for identity A, switch away and back while that task is running, reload the pending request, and dispatch it again because `begin_request()` no longer sees the original guard. This defeats the PR's per-request double-submit protection and can submit two paid state transitions. Retain guards independently of the selected view and key them by network, acting identity, and request ID; release only the guard named by its matching result, error, or timeout.

In `src/backend_task/dashpay/contact_info.rs`:
- [BLOCKING] src/backend_task/dashpay/contact_info.rs:400-407: Preserve silently fails for contact records beyond the first page
  The owner-scoped lookup stops after 100 documents and does not paginate. `found_existing_doc` controls both the `Preserve` input at lines 473-474 and the replace-versus-create branch at line 528, so a target outside that page is treated as absent: preserved fields are resolved from empty data and the code attempts to create another document. The contract's unique owner/root/derivation index may reject that create when the truncated high-water mark collides; if the selected coordinate is free, a second document with empty nickname, note, and accepted-account data can be created. Either outcome violates this PR's contact-metadata preservation guarantee. Fetch every page in deterministic order and compute the derivation high-water mark across all owned documents before concluding that the target is absent.

[Claudius-Maginificent]

@thepastaclaw fixed and independently verified.

create_or_update_contact_info's owner-scoped contactInfo lookup now paginates fully via Start::StartAfter, ordered $updatedAt ASC on the existing ownerIdAndUpdatedAt index, before concluding a target contact's document is absent — both the existing-document search and the derivation-index high-water mark now cover every page the identity owns, not just the first 100. The misleading "Get all contact info documents" comment on the old single-page fetch is corrected along with it. Added a deterministic 100+1-document pagination test (fake multi-page fetch seam) proving the loop actually walks a second page rather than asserting it in prose.

Independently re-derived severity: LOW (risk 0.51 / impact 0.15 / scope 0.18, OWASP-normalized) — real and directly relevant given this PR's own contact-metadata preservation guarantee, but gated behind an identity owning 100+ established contactInfo documents, an uncommon precondition at current adoption.

Fixed in the same commit as the identity-switch guard finding above: 27605357 on integration/review-remediation — verification complete (mutation-tested by an agent that didn't write the fix, full fmt/clippy/cargo test --all-features --workspace gate clean), pending push to origin.

[thepastaclaw]

Preliminary review — Codex only

At exact head 2760535, both carried-forward prior findings are fixed, so no prior blockers remain. The latest remediation delta introduces no new finding, but the cumulative PR range still contains three blocking legacy DashPay lifecycle and persistence defects plus one partial-success handling suggestion. Formatting and cumulative/latest diff checks passed; focused tests could not run because approval to download the pinned Tenderdash source was declined.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 3 blocking | 🟡 1 suggestion(s)

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/ui/dashpay/contact_requests.rs`:
- [BLOCKING] src/ui/dashpay/contact_requests.rs:160-163: Identity switching re-enables an unfinished paid request
  `set_selected_identity()` clears `request_in_flight` and `request_task_in_flight`, but changing identities does not cancel the backend Accept or Reject task already spawned by `AppState`. Switching away and back reloads the still-pending request with active buttons, so it can dispatch a second paid state transition while the first remains in progress. Preserve live guards independently of the selected identity and release them only for their matching task outcome or a deliberate timeout.
- [BLOCKING] src/ui/dashpay/contact_requests.rs:955-971: Navigating away can strand the paid-action guard
  This guard is released only when this persistent Contacts root screen receives the matching result. `AppState` sends ordinary task results exclusively to `visible_screen_mut()`, so navigating to My Profile, another root screen, or a detail screen before completion delivers the result elsewhere. Returning to Requests leaves `request_in_flight` set and `loading` true, and this implementation has no timeout; the spinner remains until an identity switch or restart. Move completion tracking to a task-scoped owner that survives navigation, or route correlated outcomes back to the originating screen.

In `src/ui/dashpay/contact_details.rs`:
- [BLOCKING] src/ui/dashpay/contact_details.rs:666-671: Navigating away drops the local contact-info commit
  The PR moved the local nickname, note, and hidden-state write into `commit_pending_update()`, which runs only when this screen receives the successful Platform result. The loading view still exposes Back and global navigation, so the screen can be popped before completion; because results go only to the currently visible screen, the confirmed Platform write then never updates the WalletBackend private-info sidecar. Reopening the detail or using an offline view reads the stale sidecar until a network refresh happens. Commit the sidecar in the backend success path or another task-scoped owner that survives navigation.

In `src/backend_task/dashpay/contact_requests.rs`:
- [SUGGESTION] src/backend_task/dashpay/contact_requests.rs:898-899: Sidecar failure loses the paid action's partial-success state
  `create_or_update_contact_info()` has already confirmed the paid Platform replacement before `mark_declined()` can fail. The resulting request-scoped error releases the UI guard, but without the local marker the immutable request appears again on reload; retrying performs another paid replacement before retrying the same marker. Cancellation has the equivalent split-brain path at lines 964-973. Represent this as a partial-completion outcome and retry only the idempotent marker through a durable marker-only task instead of reopening the paid action.

[thepastaclaw]

🔴 Blocking: Navigating away can strand the paid-action guard

This guard is released only when this persistent Contacts root screen receives the matching result. AppState sends ordinary task results exclusively to visible_screen_mut(), so navigating to My Profile, another root screen, or a detail screen before completion delivers the result elsewhere. Returning to Requests leaves request_in_flight set and loading true, and this implementation has no timeout; the spinner remains until an identity switch or restart. Move completion tracking to a task-scoped owner that survives navigation, or route correlated outcomes back to the originating screen.

_{source: ['codex']}

[lklimek]

Independently verified: still live, but out of this PR's scope — not fixed here.

This PR was rebased down to a single commit (f9d641f5) touching only src/backend_task/dashpay/contact_info.rs, src/ui/identity/hub_screen.rs, and src/ui/state/contacts_view.rs. src/ui/dashpay/contact_requests.rs is no longer in the diff — it reached the base via #894's squash-merge, so this is pre-existing base code rather than something this PR introduces or touches.

Confirming your diagnosis against current code rather than closing it as merely out-of-scope:

• 0fda1f67 added route_contact_request_result_to_hidden_hub / route_contact_request_error_to_hidden_hub (app.rs:1625-1647), but that forwarding is Hub-specific — it only targets main_screens[RootScreenIdentityHub], never Screen::DashPayScreen. The catch-all fallback (app.rs:1926-1931) still routes strictly to visible_screen_mut().
• ContactRequests::display_task_result / display_task_error (contact_requests.rs:930-990) therefore still clear request_in_flight / loading only when the result lands on that exact instance, and this widget has no timeout.
• The path is genuinely reachable, not dead code: Identity Hub → Settings → "Change photo" (settings.rs:250-258) → Contacts tab (dashpay_subscreen_chooser_panel.rs:29) → RootScreenDashPayContacts. left_panel.rs:19-25 documents that the Dashpay entries are hidden from nav but deliberately kept reachable.

Worth noting the modern Hub analog this PR does touch is engineered correctly for exactly this: ContactsState::reset_for_identity_change retains live guards and prunes only past REQUEST_IN_FLIGHT_TIMEOUT (contacts_view.rs:18-20, 81-99). The legacy widget has neither routing coverage nor a timeout.

Independently re-derived severity: LOW (risk 0.4 / impact 0.3 / scope 0.15) rather than Blocking. It is reachable in a few clicks, but the realistic worst case is a stuck spinner and disabled buttons on one de-emphasised legacy screen, self-healing on identity switch or restart — no double-pay (the backend try_claim_contact_request_action chokepoint blocks that independently of any UI flag) and no data loss.

Tracked as a follow-up against the legacy widget rather than fixed here, to keep this PR at the one commit that is actually its own.

[thepastaclaw]

Resolved in this update — Navigating away can strand the paid-action guard no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[thepastaclaw]

🔴 Blocking: Navigating away drops the local contact-info commit

The PR moved the local nickname, note, and hidden-state write into commit_pending_update(), which runs only when this screen receives the successful Platform result. The loading view still exposes Back and global navigation, so the screen can be popped before completion; because results go only to the currently visible screen, the confirmed Platform write then never updates the WalletBackend private-info sidecar. Reopening the detail or using an offline view reads the stale sidecar until a network refresh happens. Commit the sidecar in the backend success path or another task-scoped owner that survives navigation.

_{source: ['codex']}

[lklimek]

Independently verified: the mechanism you describe is still present in the code, but the screen containing it is currently unreachable, and the file is out of this PR's scope — not fixed here.

Scope: this PR was rebased to a single commit (f9d641f5) touching only src/backend_task/dashpay/contact_info.rs, src/ui/identity/hub_screen.rs, and src/ui/state/contacts_view.rs. src/ui/dashpay/contact_details.rs reached the base via #894's squash-merge.

The bug itself is exactly as you describe, unchanged:

• commit_pending_update() (contact_details.rs:208-247) remains the sole writer of the WalletBackend private-info sidecar (persist_contact_private_info, ui/dashpay/mod.rs:33-48), called only from display_task_result() on DashPayContactInfoUpdated (:673-684).
• The backend task performs only the Platform document write and returns DashPayContactInfoUpdated — no sidecar call anywhere in create_or_update_contact_info (contact_info.rs:523-711), including after this PR's rewrite of it.
• "Back" is rendered unconditionally (contact_details.rs:267-268), not gated on self.loading.
• I checked IdentityHubScreen::display_task_result's DashPayContactInfoUpdated arm (hub_screen.rs:559-575) as a possible alternate commit path: it only acts when pending_contact_info_tasks.remove(&key).is_some(), never calls persist_contact_private_info, and is a no-op for a key it did not register. There is no backend-side or Hub-side fallback commit.

What changes the priority: a repo-wide search for DashPayContactDetails finds ScreenType::DashPayContactDetails defined and pattern-matched only inside src/ui/mod.rs's own enum/match machinery — zero call sites construct it, in production UI, tests, or MCP/CLI. Contact clicks route to DashPayContactProfileViewer instead (contacts_list.rs:836-837, contacts.rs:520-526). So the screen compiles and is exhaustively matched, but nothing in the shipped app can navigate to it.

Severity as shipped: INFO (risk ≈ 0, scope ≈ 0 — unreachable). As latent code it is a real landmine: restoring navigation to this screen, or reusing the screen-scoped-commit pattern, reactivates the bug with no other code change. Note contact_profile_viewer.rs:144 independently calls persist_contact_private_info — worth a look under the same lens, though outside what I verified here.

Tracked as a follow-up (fix the pattern, or delete the unreachable screen) rather than fixed in this PR.

[thepastaclaw]

Resolved in this update — Navigating away drops the local contact-info commit no longer present.

_{Auto-resolved by the review system based on the latest commit diff. If you believe this was closed in error, reopen the thread.}

[thepastaclaw]

Preliminary review — Codex only

At exact head f9d641f, two carried-forward blockers remain: hidden legacy Requests screens miss correlated completions, and popped contact-detail screens lose their local sidecar commit. The latest delta adds one blocker in the full contact-info scan; repeated protected-wallet prompts and failures from later invalid derivation indices are both valid consequences of the same loop and are combined below. The shared backend claim and durable action phases fix the other two prior findings.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 3 blocking

2 carried-forward finding(s) already raised on this PR; not re-posting as new inline comments.

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/backend_task/dashpay/contact_info.rs`:
- [BLOCKING] src/backend_task/dashpay/contact_info.rs:467-482: The full scan repeatedly unlocks the wallet and can fail after a match
  The new full-owner scan invokes `derive_contact_info_keys()` for every valid document, including every document after `existing` has been populated. Each call enters `SecretAccess::with_secret`; with the default `RememberPolicy::None`, a protected wallet is decrypted only for that call, so an identity with 101 contactInfo documents can require 101 password submissions for one save, decline, cancel, or unhide. Continuing after a match also propagates unrelated derivation failures: the contract permits any non-negative integer, but hardened BIP32 rejects indices at or above 2^31, so a later document can abort an already-successful lookup. Compute the public high-water mark without key access, hold one secret session while deriving candidate keys, and stop deriving once the target is found.

[thepastaclaw]

Preliminary review — Codex only

At exact head 2c69239, focused tests could not compile because the build requires an unavailable Tenderdash download. Carried-forward prior findings: the identity-switch and partial-success defects are fixed; the legacy spinner defect remains real but is intentionally deferred outside the current three-file PR diff; the Contact Details defect is outdated because that screen is unreachable. New findings in the latest delta: the mutable pagination cursor and underivable high-water allocation are blocking defects.

Validated blockers were found in the Codex precheck. Sonnet is deferred until a fresh Codex revalidation clears the blocker gate.

Review provenance

• Codex reviewers: gpt-5.6-sol — general (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — general (failed), gpt-5.6-sol — general (completed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — rust-quality (failed), gpt-5.6-sol — rust-quality (completed)
• Verifier: gpt-5.6-sol — verifier
• Sonnet: not run (deferred by blocker gate)

🔴 2 blocking

🤖 Prompt for all review comments with AI agents

These findings are from an automated code review. Verify each finding against the current code and only fix it if needed.

In `src/backend_task/dashpay/contact_info.rs`:
- [BLOCKING] src/backend_task/dashpay/contact_info.rs:521-525: Mutable pagination order can skip contact records
  The scan orders documents by `$updatedAt`, then continues with the last document ID from each page. Platform resolves that ID to the document's current contents before constructing the next index query. If another contact-info operation replaces the boundary document between requests, its updated timestamp moves it later in the index, so the next page starts from the new position and skips documents between the old and new positions. Operations for different contacts or request IDs are not serialized per owner. An omitted target is therefore treated as absent, causing creation with incomplete allocation metadata; this can create a duplicate contact record or fail on an index collision. Use a stable owner/key index for pagination or serialize the complete scan-and-write operation per owner.
- [BLOCKING] src/backend_task/dashpay/contact_info.rs:486-489: Skipped invalid index still poisons new-contact allocation
  The DashPay contract accepts every non-negative integer derivation index, while hardened BIP32 accepts only values below 2^31. The lookup now skips a document whose index cannot be derived, but this calculation still advances `next_derivation_index` beyond that document. When no existing document matches the requested contact, `create_or_update_contact_info` passes the resulting underivable value to key derivation and fails. One contract-valid high index therefore prevents this identity from creating contact information for every new contact. Track occupied derivable indices and choose an unused value below 2^31 instead of advancing beyond an index the key API cannot represent.

[thepastaclaw]

🔴 Blocking: Mutable pagination order can skip contact records

The scan orders documents by $updatedAt, then continues with the last document ID from each page. Platform resolves that ID to the document's current contents before constructing the next index query. If another contact-info operation replaces the boundary document between requests, its updated timestamp moves it later in the index, so the next page starts from the new position and skips documents between the old and new positions. Operations for different contacts or request IDs are not serialized per owner. An omitted target is therefore treated as absent, causing creation with incomplete allocation metadata; this can create a duplicate contact record or fail on an index collision. Use a stable owner/key index for pagination or serialize the complete scan-and-write operation per owner.

_{source: ['codex']}

[thepastaclaw]

🔴 Blocking: Skipped invalid index still poisons new-contact allocation

The DashPay contract accepts every non-negative integer derivation index, while hardened BIP32 accepts only values below 2^31. The lookup now skips a document whose index cannot be derived, but this calculation still advances next_derivation_index beyond that document. When no existing document matches the requested contact, create_or_update_contact_info passes the resulting underivable value to key derivation and fails. One contract-valid high index therefore prevents this identity from creating contact information for every new contact. Track occupied derivable indices and choose an unused value below 2^31 instead of advancing beyond an index the key API cannot represent.

_{source: ['codex']}