0011967: Android wallet: P2P receipt takes two minutes with concurrent reserve long polls - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update
0011967	Taler	wallet (Android App)	public	2026-11-08 17:41	2026-11-08 17:42

Reporter	bot-codex-florian-dold [agent]	Assigned To		Resolution deadline
Implementer	avalos	Reviewer
Release signed by		Deployed by
Verifier		Communicator	CM_7
Data protection authority notification required	No
CSIRT notification required	No
Estimated effort (hours)		Actual effort (hours)	0
Fast-track	No
Work package	none
Priority	normal	Severity	minor	Reproducibility	have not tried
Status	new	Resolution	open

Summary	0011967: Android wallet: P2P receipt takes two minutes with concurrent reserve long polls
Description	Receiving a P2P push payment in the Android nightly wallet took approximately two minutes. Suspected cause: background reserve long polls occupy the shared OkHttp dispatcher's per-host request slots, delaying foreground payment requests. Observed in log-ivan.txt, November 8, 2026: - 10:55:32: preparePeerPushCredit starts. - Contract fetch: 28,425 ms, HTTP 200 (line 2361). - Purse deposit-status fetch: 30,406 ms, HTTP 200 (line 2725). - Preparation completes at 10:56:31 after 59,164 ms (line 2810). - Confirmation at 10:56:34 returns in 7 ms. - Purse merge: 25,601 ms, HTTP 200 (line 3505). - Withdrawal of received funds: 28,060 ms, HTTP 200 (line 4527). - P2P credit task finishes successfully at 10:57:32 (line 4845). These four HTTP waits account for 112.5 seconds. Requests complete alongside batches of background reserve polls using timeout_ms=30000. Multiple pending withdrawals poll the same exchange concurrently. Current Android source uses a shared Ktor/OkHttp client in wallet/src/main/java/net/taler/wallet/backend/NetworkInterface.kt. taler-kotlin-android/src/main/java/net/taler/common/HttpUtils.kt does not override dispatcher limits. OkHttp defaults are 5 concurrent asynchronous requests per hostname and 64 per dispatcher. ConnectionPool(5, ...) controls idle connections, not request concurrency. The suspected mechanism is per-host request-slot saturation: each sequential P2P request waits for another background polling round. The log measures end-to-end HTTP duration and cannot conclusively distinguish local queueing from server latency. Verify dispatcher queue time and configuration in the affected APK. Wallet-core version: 1.6.49, git 9b08843c54a93d83b2df70cad9d25093b85720e1. Android package: net.taler.wallet.nightly. Database: SQLite. Suggested investigation/fix: measure enqueue-to-execution time and ensure background long polls cannot starve interactive requests, for example through separate dispatchers/clients or suitable concurrency limits. Validate with several pending reserves on the same exchange while receiving a P2P payment. Requested assignee: Ivan Avalos (avalos). The reporting API account lacks permission to assign issues.
Tags	No tags attached.