|
|
The fork commit (4740d97 in the signel fork) added a request-callback table, extended signel--send-rpc with an optional success-callback, and routed result responses through signel--dispatch. These tests lock that contract from the consuming project so a future fork change can't silently break the picker that will read listContacts through it.
Five tests, Normal / Boundary / Error categories plus a reconnect-invalidation case:
- result-invokes-callback (Normal): a result response with a registered id fires the callback with the value and removes the handler.
- send-rpc-registers-success-callback (Normal): passing a success callback stores it under the returned id.
- unknown-id-is-noop (Boundary): a result with no registered id is silent — no receive or error handler fires, map stays empty.
- error-cleans-up-handler (Error): an error response removes the handler without firing the callback, so a retry starts clean.
- stop-clears-handler-map: signel-stop empties the map, so a restart can't replay stale callbacks waiting on responses that will never arrive.
The dispatch tests synthesize JSON alists directly. No live process is needed. The send-rpc test stubs get-process and process-send-string so it doesn't need a running signal-cli.
Refactor audit on signel.el surfaced one unrelated pre-existing smell I'm not fixing here: signel--handle-error reads from signel--request-buffer-map but never remhashes, so error responses leak request-id → buffer-name entries. Filed as a separate [#C] follow-up under the Signal parent task; the maps clear on stop/start so the impact is bounded to a single live session.
todo.org: the dispatch task flips to DOING (the fork commit is in, the test contract is locked) and gets the leak follow-up appended.
|
