One chat REQ per trade trips nos.lol's 'too many concurrent REQs'
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Domain
- backend-api-design, networking
Research direction
Start with resubscribe_active_chats and the subscription helpers in rust/src/api/messages.rs, then read docs/RELAYS.md and the existing bulk kind-14 DM subscription pattern. The issue offers two possible approaches but does not choose between them, so clarify the intended scope before implementing. Done should mean active trade chats no longer exceed the relay's concurrent-REQ limit and refused subscriptions do not silently leave messages unreceived.
Written by the indexing model from the issue text.
Description
Problem
resubscribe_active_chats (rust/src/api/messages.rs ~l. 1569) opens one subscription per trade that can still chat (chat_still_relevant: any non-terminal status with a counterparty), id mostro-chat-<order> (chat_subscription_id). With a few dozen such trades plus mostro-dm, mostro-orders, mostro-orders-recent, mostro-relay-list and the per-trade mostro-daemon-*, the app exceeds nos.lol's concurrent-REQ limit.
Observed
After a seed import, a log report shows ~30 mostro-chat-* subscriptions and, on wss://nos.lol, repeated:
[WARNING] relay: notice relay=wss://nos.lol msg=ERROR: too many concurrent REQs
Any REQ the relay refused does not exist there — peer chat, dispute chat or daemon messages for those trades are silently not received from that relay (live_subs re-issues on connect, not on a NOTICE refusal; see docs/RELAYS.md).
Contributing factor
Rows recovered from history that never reach a terminal status keep a chat REQ open forever. A seller's completion only arrives through the public Kind 38383 success (the daemon sends PurchaseCompleted to the buyer only), so restored seller trades parked at SettledHoldInvoice / Pending qualify as "live" — tracked separately (restored orders shown as in progress).
Options
- Merge the chat filters into one (or a few) subscriptions: a single REQ whose
#plists everypub(K_conv), replaced throughlive_subs::replaceas trades come and go — the same pattern as the bulk kind-14 DM filter. - Treat a
too many concurrent REQsNOTICE as a failed REQ and back off / consolidate, rather than assuming it exists.
Related: #182 (subscription lifecycle: leaks and deterministic ids — not the count).
🤖 Generated with Claude Code
- Dominant language
- Dart
- Stars
- 11
- Forks
- 9
- Avg merge
- 12h 41m
- Merged PRs (30d)
- 265
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MostroP2P/app
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Add-invoice screen stays on "Sent, waiting for the node" after a late acceptance on a sell orderOpenbug priority: medium
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
area: ui
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MostroP2P/app#341 · 1 comment ·
Maintainers usually reply within 1 day
Similar issues
-
Server never consumes the request body on early-error paths: _sinkIncoming does not resume the paused subscriptionMay be free again A pull request for this issue was closed without being merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
[BUG][All] VLESS URIs with flow=xtls-rprx-vision-udp443 are silently dropped on subscription importOpen
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
simonoppowa/OpenNutriTracker#1336 ·
Maintainers usually reply within 1 day
-
area::timeline needs::triage regression
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
linagora/twake-on-matrix#3450 ·
Maintainers usually reply within 3 days
-
[Request]: Flut RenamerPossibly taken @scillidan claimed this today. Openpackage-request
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
ScoopInstaller/Extras#18972 ·
Maintainers usually reply within 1 day