My Emacs configuration https://git.cjennings.net/dotemacs/atom?h=main 2026-05-28T02:55:39+00:00 2026-05-28T02:55:39+00:00 Craig Jennings c@cjennings.net 2026-05-28T02:55:39+00:00 urn:sha1:bfec0eab1132b7713a35500323e06ebea2da17a4 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.