Repository navigation
[Bug]: Shop Paykit request never arrives after restore; Encrypted Link stuck in recovery_required #1402
Description
What happened?
Pubky Shop canary #2 on restored identity The Piotr (pubkyu5r19jcb1xfoh9szp6w4jmsfsy1hbgjpysjw6h1eyqo66x7uxmfy, ~7k on-chain). Seller Pav C Tester (pubkyadjnbqbam6b6nkcjp8iarxorjmqycxo6cwfzxspeyxaqjxmnjdcy).
Checkout for listing order 9b3adc7f asked Pay exactly ₿1,026 (Items ₿1,000 · Payment code ₿26). Shop showed “Delivered to your wallet. Open Bitkit to pay.”
After restore, Pav was not in contacts. Payment never arrived. After adding the contact (06:53:56 UTC), payment still never arrived. Logs then loop on Encrypted Link failure for that counterparty:
Failed to queue private Paykit endpoints for 'pubkyad…xmnjdcy' during 'foreground':
recovery required: Encrypted Link recovery is required for counterparty adjnbqbam6b6nkcjp8iarxorjmqycxo6cwfzxspeyxaqjxmnjdcy
and repeated:
Failed to advance private Paykit link … [Transport='code=transport_error, context=clear Encrypted Link outbox']
No Decoded incoming for 1026 in the session logs.
After the Shop payment window expired, a different request appeared in Bitkit: Sept 28 ₿1,255 “Accepted” (first canary / insufficient-funds leftover), not 1026. Pay and Dismiss both toast “Payment request operation is already in progress” (PaykitPaymentRequestError.OperationInProgress).
Related / prior: closed #1348 (same class, closed after retry fix), open iOS twin #776, session recovery work #1093. Marketplace thread: BitcoinErrorLog/pubky-marketplace#54.
Expected behavior
- After adding the seller as a contact (or if checkout can target a non-contact), Encrypted Link recovers or surfaces a clear recovery UI — not a silent outbox-clear loop.
- New Shop payment request (1026) is decoded and shown as payable while the window is open.
- Stale Accepted requests after a failed send are dismissible / payable again, or no longer show Pay/Dismiss that only toast
OperationInProgress. - Shop “Delivered to your wallet” should only appear when the wallet actually accepted the request (wallet-side; Shop may need an ack — called out on fix: add vertical scroll #54).
Steps to Reproduce
- Restore The Piotr seed on mainnet Bitkit (identity that previously failed a Pav Shop pay for insufficient funds / stuck PR).
- Confirm Pav C Tester is not in contacts.
- Open listing, checkout for ~1000 sats → order with payment code (here
9b3adc7f/ total 1026). - Observe Shop “Delivered…” while Bitkit never shows the new request.
- Add Pav as contact; wait / foreground app — link stays
recovery_required. - Let Shop window expire.
- Open the old Sept 28 1255 “Accepted” request → tap Pay or Dismiss → toast “Payment already in progress” / “Payment request operation is already in progress”.
Workaround that previously worked for #1348: fresh Bitkit profile with seller already a contact — not retested here.
Logs / Screenshots / Recordings
| Shop awaiting (1026) | Shop expired | Bitkit stale Accepted (1255) |
|---|---|---|
![]() |
![]() |
![]() |
Full Bitkit logs zip could not be uploaded via API (content-type rejected). Key lines from the Oct 1 session are quoted above; staged zip:
2026-10-01-shop-canary2-paykit-recovery-logs.zip
2026-10-01 06:53:56.582 INFO Added contact 'pubkyad…xmnjdcy'
2026-10-01 06:59:23.167 WARN recovery required: Encrypted Link recovery is required for counterparty adjnbqbam6b6nkcjp8iarxorjmqycxo6cwfzxspeyxaqjxmnjdcy
2026-10-01 06:59:55.216 WARN clear Encrypted Link outbox
Bitkit Version
Mainnet debug build from master (canary device install; exact versionName TBD if needed from APK).
Device / OS
Samsung Galaxy S22, Android 16
Reproducibility
Often (>50%) — reproduced on this restored identity; fresh-wallet workaround previously avoided it.
Additional context
- Restored wallet / poisoned private link to seller after earlier failed Shop canary.
- On-chain Paykit (private contact-gated); no Lightning channel involved for this pay.
- Mainnet / shop.pubky.app.
- Listing:
https://shop.pubky.app/marketplace/listing/adjnbqbam6b6nkcjp8iarxorjmqycxo6cwfzxspeyxaqjxmnjdcy/3556805865a5490cb74f99ab95f43555 - Order ID
9b3adc7f; expected amount 1026; stale UI amount 1255.



Activity
piotr-iohk commentedon Oct 1, 2026
fyi @ben-kaufman
ben-kaufman commentedon Oct 1, 2026
The rc58 SDK used by #1401 removes the outbox cleanup step that was blocking encrypted-link recovery in these logs.
Please retest with #1401 and the matching Paykit Server #33, checking whether a fresh Shop request arrives after restoring the profile and whether Pay/Dismiss remain usable.
These PRs do not migrate old receiver-folder data, so the retest needs a compatible shared-state setup and a fresh request. The historical request is not expected to carry over through this upgrade.
Keeping this issue open pending verification.
ben-kaufman commentedon Oct 15, 2026
Can we close this issue? Or still happening?
ben-kaufman commentedon Oct 15, 2026
RC77 retest status: the real Shop staging site is blocked by HTTP authentication (
net::ERR_INVALID_AUTH_CREDENTIALS), and authenticated test access is not currently available. No new Shop order/request or restore-to-request delivery was exercised. I did not substitute a local issuer or count the separate profile/import recovery tests as a Shop pass. Keeping this open; verifying it still requires a fresh compatible Shop request before/after restore, not the historical pre-shared-state order.