[Bug]: Continue on Let your contacts pay you does not finish

[piotr-iohk]

What happened?

After importing a Pubky Ring profile with 61 contacts, Continue on "Let your contacts pay you" stays busy for a long time. It does finish. The session log shows why it takes that long.

Saving the 61 contacts was the shorter part. On 1 Oct 2026 at 15:38:02 the app had already discovered 61 follows. Import finished at 15:39:28. The following work is a walk of Paykit receiver paths. From 15:35:49 through 15:57:28 the log records 68 failures, all transport_error / list_paykit_receiver_paths, and all for the same 7 pubkys (about 9–10 failures each). Those are the same 7 keys whose profile fetch had just failed with transport_error / fetch profile while the import preview was loading. The log ends while those retries are still going, which matches Continue staying on screen for many minutes.

Expected behavior

Continue finishes promptly after the contacts are saved, with visible progress while any remaining work runs. A contact whose profile lookup already failed should not be retried for the rest of the session.

Steps to Reproduce

1. Use Pubky Ring with an identity that follows 61 pubkys, and a Bitkit wallet that has not saved those contacts yet.
2. In Bitkit, adopt that Ring identity and wait until the import preview lists the contacts.
3. Import the contacts.
4. On "Let your contacts pay you", tap Continue.
5. Continue stays busy for many minutes, then finishes.

Logs / Screenshots / Recordings

From bitkit_2026-10-01_15-33-29.log (device local time):

• 15:38:02 Discovered '61' contacts for import
• 15:38:08–15:39:01 seven Retrying contact profile resolution warnings, transport_error / fetch profile
• 15:39:28 Imported '61' contacts
• 15:35:49–15:57:28 sixty-eight Failed to refresh Paykit receiver paths, all list_paykit_receiver_paths, only those same seven pubkys

The full log could not be attached from the command line:

2026-10-01-pay-contacts-continue-hang.log

Bitkit Version

2.5.0 dev, pull request #1395 at faae845c. Confirm this was the build on the phone.

Device / OS

Samsung SM-S901B. OS version TBD. Pubky Ring 2.0 was installed from bitkit-e2e-tests/aut/pubkyring-83834e7.apk.

Reproducibility

Often (>50%)

Additional context

• One 61-contact Ring import on this build. Device log times are local. Continue was still in the receiver-path retries at the end of the exported log. The reporter later saw that step finish.
• The same seven pubkys fail both fetch profile during preview and list_paykit_receiver_paths afterward. The other follows are not in those failure lines.
• Loading the contact list and avatars is separate and already covered by fix: speed up pubky profile loading #1399 and fix: speed up pubky profile loading bitkit-ios#854. This report is only the Continue / receiver-path walk.
• fix: save contacts without repeated remote lookups #1395 lists this Continue path as out of scope.
• Environment: regtest app build, staging Pubky.
• Twin: iOS issue filed in the same batch and linked after both numbers exist.

[piotr-iohk]

Twin: synonymdev/bitkit-ios#861

[ben-kaufman]

This matches iOS #861. Could you retest with #1401? It removes the receiver-folder discovery producing these warnings. #1395 fixes saving imported contacts, but does not address this later Continue delay. If it persists, please include logs covering the Continue tap through completion or failure.

[piotr-iohk]

Checked on #1401 latest revision 5fb0193.

Test: import profile from Pubky Ring with 61 contacts.
Performance seems deteriorated from testing against #1395 - not only continue, but all 3 steps: create, import, continue.

Logs and recording (continue never finished after 15mins +):

Screen.Recording.2026-10-02.at.09.57.00.mp4

logs.zip

[Jasonvdb]

@ben-kaufman, here are measurements for this issue from our 61-follow test, in case they help with #1401.

Setup: emulator, staging network, piotr's Pubky Ring follow list (61 follows, 7 of them never published). Builds: master 6ba44a4, and #1399 at 58d5c53, which already runs public reads outside the operation lock. Line numbers are at 58d5c53.

Continue (tap → setEnabled done): 339 s on master, 154–167 s on #1399.

• Breakdown of fix: speed up pubky profile loading #1399's 167 s:
  • Public endpoint sync: 2.0 s.
  • Private walk: 137.8 s, 83% of the total. Of that, receiver-folder discovery (discoverRelevantReceiverPaths) took 93.9 s, marker selection 29.4 s and ensureLinkWithPeer 13.7 s.
  • syncLists: 4.9 s.
  • Message drain: 21.7 s.
• The walk handles one contact at a time (preparePrivatePaymentListReservations, PrivatePaykitRepo.kt:853). The 7 unpublished follows cost about 8 s each, 54–58 s in total; every other contact cost about 1.5 s.
• Each walk fetches every receiver marker twice: once during discovery and again in privateReceiverPathSelection (PaykitSdkService.kt:697).
• When the import ends, the contact sync (AppViewModel.kt:771) starts a second walk over the same 61 contacts (148 s). It runs alongside Continue and competes for read slots and the operation lock.

After Continue, walks over all 61 contacts keep running back to back for more than 10 minutes, on both builds.

• Payment request polling took 290 s, link burst round 1 took 378 s, and so on. The initial link burst schedules 15 rounds (PrivatePaykitRepo.kt:94).
• In 13.6 minutes, each contact's discovery and marker selection ran about 5 times.
• ensureLinkWithPeer holds the operation lock during network I/O, 179 s in total (PaykitSdkService.kt:773-784).

Delete Profile with 61 contacts: 551 s on #1399.

• 520.7 s of that was waiting for publicationMutex (PrivatePaykitRepo.kt:1360-1361, taken through removePublishedEndpointsForCleanup). It waited behind a 362 s foreground publish walk and a polling walk queued ahead of it.
• The delete work itself took about 30 s: deleteAllContacts was 24 s (61 × 0.4 s).
• On master, removing the 61 contacts right after launch took 930 s, queued on the operation lock behind profile reads.

Import All → saved: 28–41 s on both builds.

• About 70% of it is the Kotlin storage callbacks. Each saveContact does about 8.5 full state loads plus one full save. Each load is a Room walletIndex query, a DataStore read and a Keystore AES-GCM decrypt.
• The state is only 12.6 KB with 61 contacts, so the cost comes from the number of calls, not the size.

The 7 failing follows:

• Six have no pkarr record on the relays. The seventh points to a homeserver key that has no record either.
• They fail in 5–9 s on the emulator and in 5–15 s on piotr's Samsung.
• piotr once saw them take about 5 minutes. A slow DHT is the likely cause, because the pkarr and DHT lookups have no overall deadline.

Ideas, in case they're useful (none of them are in #1399):

• Let Continue return after the public sync, and finish the private preparation in the background.
• Reuse the markers fetched during discovery.
• Read 3–4 contacts at a time on the bulk lane.
• Cancel or merge the contact-sync walk when Continue starts.
• Skip keys that just failed to resolve for a few minutes.
• Cancel background publication work before Delete takes publicationMutex.
• Cache walletIndex in Keychain.

Separately, #1399 now gives each import-preview lookup a 10 s deadline, and Contacts no longer looks up every contact again on each visit.

[ben-kaufman]

Addressed the blocking contact-preparation path in #1401, commit eaf6a09; matching iOS changes are in 27e921a3.

Continue now finishes public setup and starts private preparation in the background. Repeated preparations are coalesced, established links are reused, and unavailable lookups have a five-minute cooldown. Link preparation no longer holds the publication lock for the entire contact walk; cleanup invalidates the remaining work, and removed contacts are checked again before publication.

All 3,186 Android unit tests passed, including stalled lookup/cleanup, removed contacts and duplicate preparation. An in-flight SDK call can still take time, and public setup still needs the network. Please retest the 61-contact fixture on the new head; keeping this issue open until that device run confirms the Continue and Delete timings.