0011953: wallet-core: prioritize payment continuations over optional maintenance work

ID	Project	Category	View Status	Date Submitted	Last Update
0011953	Taler	wallet-core	public	2026-11-05 08:59	2026-11-05 08:59

Reporter	bot-codex-florian-dold [agent]	Assigned To		Resolution deadline
Implementer		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	feature	Reproducibility	have not tried
Status	new	Resolution	open

Summary	0011953: wallet-core: prioritize payment continuations over optional maintenance work
Description	Wallet-core needs an explicit cooperative scheduling policy that gives interactive operations and their dependencies precedence over optional background reporting, while retaining bounded progress for maintenance. Motivation: an Android wallet-core 1.6.49 log (9b08843c54a93d83b2df70cad9d25093b85720e1) shows bulk denomination validation repeatedly starting wallet-wide refresh-cost calculations during payment processing. This investigation also found a concrete Qtart event-loop starvation bug. That runtime bug must be fixed independently; scheduling priorities in wallet-core cannot deliver an HTTP completion that Qtart has never dispatched. The existing TaskRunLimiter provides FIFO admission limits (32 global handlers, with a smaller pool of 4 for PendingTaskType.Refresh). It is not a priority scheduler for continuations of already-running tasks. The smaller refresh pool applies to coin-refresh handlers, not every maintenance operation such as refresh-balance. There is no evidence in this capture that exhaustion of admission permits was the cause of the payment delay. This issue is a scheduling-policy improvement motivated by the observed interference, not a claim that all recorded payment latency would be fixed by priority queues alone.
Steps To Reproduce	After fixing runtime I/O fairness, exercise a payment concurrently with a large denomination-validation backlog and repeated refresh-cost report invalidations. Record time spent runnable but waiting for a cooperative execution slice, separately from network wait, database work, and actual execution. Cover payment dependencies: if the payment needs exchange information or denomination validation, that specific work must be able to run promptly even when unrelated maintenance is deferred. Also exercise cancellation, a stalled network request, a long-lived waitTransactionState request, and sustained foreground traffic.
Additional Information	Related issues: - Runtime fairness: https://bugs.taler.net/n/11951 - Bounded computation and coalescing: https://bugs.taler.net/n/11952 Suggested scope and acceptance criteria: - Distinguish interactive execution and required dependencies from optional refresh-cost reporting and unrelated maintenance. - Apply priority at cooperative continuation/work-slice boundaries, not only when admitting a whole task. - Propagate priority to work needed to unblock an interactive operation; do not defer all denomination validation indiscriminately. - Give maintenance a bounded share of execution so continuous interactive activity cannot starve it indefinitely. Preserve timely safety-critical refresh work. - Do not suspend all maintenance for the entire lifetime of a payment or progress waiter: network waits and waitTransactionState can be long-lived. Track runnable work separately from external waits. - Preserve cancellation, transactional correctness and existing task wakeup/rerun behavior. - Add contention tests showing improved foreground scheduling latency and continued maintenance progress, including when the foreground operation stalls or is cancelled. Relevant files: packages/taler-wallet-core/src/shepherd.ts and task-run-limiter.ts, plus the cooperative yield/work-budget mechanism used by CPU-heavy maintenance. No particular priority API or number of priority classes is prescribed; the observable scheduling and liveness guarantees should drive the design.
Tags	No tags attached.

View Issue Details

Required notifications

Activities

Issue History