David Dudok de Wit de526521ab fix(gateway): let a serial reader return once a busy burst input is held ...

Signal and IRC await handle_message before they read their next input.
A busy photo or queue-mode text was held for the burst window and the
call returned only after the durable commit, so the burst's next input
could arrive only once the burst had committed alone: two turns where
main merged one, and the reader stalled about 0.38 s per busy input.

An adapter now declares serial_receive_loop when it delivers a chat's
next input only after handle_message returns and returning triggers no
acknowledgement. For it, dispatch_busy_burst returns as soon as the
input is held, as main returned once the input was merged into the
pending slot. The burst still commits once and in order, and a failed
commit is logged. Every other adapter keeps commit-before-return.

The reader still never runs ahead of what it returned on:
- a command first waits until every earlier input of that reader has
  committed (/stop, /new and /reset drop their own chat's held burst),
  so /restart cannot close admission under a held input and /new
  cannot miss one still committing;
- a chat holds at most one uncommitted burst: the next one waits for
  that commit, as main's reader waited at its first commit.

Flagged: Signal, IRC, email, Matrix, Mattermost, ntfy, Photon, SimpleX,
WeCom, WhatsApp and Feishu. Buzz is left out: it saves its cursor only
after the call returns.

Refs #134889
Fixes #140538

(cherry picked from commit e72e05a1e6e415ff54426b205dcc6b6f408417cf)

2026-10-18 03:15:07 -07:00

..

__init__.py

…

adapter.py

fix(gateway): let a serial reader return once a busy burst input is held

2026-10-18 03:15:07 -07:00

plugin.yaml

…