- Shipped
- September 2, 2026 at 11:42 PM UTC
- Author
- Kamo
- Commit
- 49345c7
Extension 8777 (Aiden Perry, kamocrm) was created from KamoCRM on 2026-09-02 and never rang. The FreePBX GraphQL `addExtension` mutation had written `users`, `devices`, 54 rows of `sip` and the whole `AMPUSER/8777/*` astdb tree — and then called `needreload()`, which raises the GUI's "Apply Config" flag and nothing else. `retrieve_conf` never ran, so `pjsip.endpoint.conf` was still the one generated on Aug 27 and the running Asterisk had no endpoint at all: [2026-09-02 21:05:28] ERROR chan_pjsip.c: Unable to create PJSIP channel - endpoint '8777' was not found The caller heard no error. The attendant's `_[3-9]XXX` handler validates the extension against astdb, which WAS populated, so the call was accepted, handed to kamo-direct-connect, and died on CHANUNAVAIL in milliseconds; with `voicemail=novm` the no-answer branch routes back to the main queue, so the caller simply heard the main line ring again. The CDR row for the real call reads **************** Every mutation in FreePBXProvider now ends in applyConfiguration(), which issues the `doreload` mutation and polls `fetchApiStatus` to a terminal state — `doreload` shells out to a background `fwconsole api doreload`, so an accepted mutation is not an applied one. A live k1m1 apply completes in 3-4s. Failures are logged, never thrown: the write has already succeeded on FreePBX by that point, so failing the request would leave Kamo without a phone_extension row for an extension FreePBX already holds, and the obvious retry would come back "This device id is already in use". A pending reload is recoverable — the next write applies it, as does the GUI's Apply Config. Verified end to end against the live k1m1 box with a throwaway extension: after addExtension alone `pjsip show endpoint 8999` reported "Unable to find object 8999"; after doreload the endpoint was there. Then deleted, applied, and confirmed gone with no astdb residue.