Thanks — I’ll explain what the code does, when it’s used, and then walk through the most likely causes for a SIP trunk being removed automatically and next steps / diagnostic actions you can take to find the root cause. What this function does (plain language) • This is a test/double implementation method — part of a fake/mock store named

FakeSIPStore

. It’s used in unit tests to stand in for the real SIP storage layer. • The method signature: ◦

StoreSIPInboundTrunk(ctx context.Context, info *livekit.SIPInboundTrunkInfo) error

◦ It records that the method was called and stores the supplied arguments for later inspection. • Key behaviors: ◦ It locks a mutex so concurrent test goroutines won’t corrupt the fake’s internal state. ◦ It appends the call’s arguments to

storeSIPInboundTrunkArgsForCall

so tests can assert that the method was called with expected values. ◦ It records an invocation via

fake.recordInvocation("StoreSIPInboundTrunk", ...)

— useful for verifying calls across the fake. ◦ If a test provided a custom stub function (

StoreSIPInboundTrunkStub

), it calls that stub and returns its error/result — this lets tests customize behavior. ◦ If a return override for this specific call index exists (

storeSIPInboundTrunkReturnsOnCall[...]

), it will return that configured error. ◦ Otherwise it returns a default preconfigured result (

storeSIPInboundTrunkReturns.result1

). • When it is used: ◦ In unit tests or integration tests that need to simulate storing an inbound SIP trunk without hitting a real database or store. ◦ Tests will assert that StoreSIPInboundTrunk was called with correct values, or arrange for it to return an error to test error paths. Why this code is unlikely to be the cause of trunks being deleted in production • This is a fake test store — it only runs in tests. It does not run in your production/service process unless you intentionally swapped in the fake implementation in a non-test environment. • A fake’s behavior (recording calls, returning pre-configured results or stubs) won’t remove real entities in a live system. Likely causes for SIP trunks being deleted automatically (Choose items relevant to your setup — these are common causes in systems that manage SIP trunks) • Automated cleanup/TTL process ◦ A background job might clean up trunks after a time-to-live (TTL) or inactivity threshold. ◦ Check scheduled jobs, cron tasks, or any “cleanup” goroutines in your service. • Reconciliation or config-sync process ◦ A config management or reconciliation loop might overwrite store state from a canonical source and remove trunks that aren’t present there. ◦ Confirm whether a sync process periodically writes the canonical list of trunks. • Expiry or lease mechanism ◦ Trunks might be stored with an expiry/lease key that is not being renewed. ◦ Look for code that writes an expiry timestamp, heartbeat, or lease and code that deletes expired entries. • Race condition / accidental deletion in production code ◦ A bug could trigger a delete path (e.g., handling a particular API call, error path, or failure) that removes trunk entries. ◦ Search for delete/remove methods and places they are invoked. • Persistence/storage issue ◦ If you use an external datastore (redis, db, etc.), issues like evictions (Redis LRU), TTLs, schema migrations, or replication problems could remove rows/keys. ◦ Check datastore logs/metrics for evictions/expired keys or failed writes. • Permission or deployment automation ◦ A deployment or automation script might reset configuration or call an API that removes trunks. ◦ Check deployment/infra automation run logs. • Operator/API user action ◦ A script, user, or external system calling the API could be deleting trunks unintentionally. ◦ Check access logs and audit trails for delete operations and which principal triggered them. Diagnostic steps to find the root cause 1. Confirm environment ◦ Are you running a production service or tests when trunks disappear? If disappearance happens in production, confirm the real store implementation is used (not the fake). 1. Search code for delete paths ◦ Grep for functions like

DeleteSIP*

,

RemoveSIP*

,

Expire*

, or any place that calls the store’s delete functions. Note callers and conditions. 1. Enable/inspect logging and audit ◦ Increase logging around trunk create/update/delete operations and around any reconciliation/cleanup jobs. ◦ Capture who/what triggered the delete (trace request ids, user/service principal). 1. Check datastore behavior ◦ If using Redis, check key TTLs and eviction metrics. ◦ If using SQL, check row timestamps and any scheduled cleanup or partition drops. 1. Reproduce in a controlled environment ◦ Try to reproduce the deletion in a staging environment with debug logs enabled. Add instrumentation to record when the delete path is invoked and the stack trace. 1. Inspect background jobs / cron / reconciler ◦ Look for scheduled tasks which run every few hours and might coincide with deletions. 1. Correlate timestamps ◦ When a trunk is created, note timestamps. When it disappears, check system and application logs around that timestamp to find the delete caller. What I can help you do next • If you want, I can help narrow this down by asking a few quick questions: a. Are trunks being removed in production or only during tests? b. What store/backend are you using for SIP trunk persistence (Redis, Postgres, etc.)? c. Do you have a reconciliation / cleanup job or TTL configured (or any cron jobs) that runs periodically? d. Can you share the delete/remove function(s) for SIP trunks or any background job code that touches SIP storage? • Based on your answers, I can provide a focused checklist, code locations to inspect, or a small instrumentation snippet you can add to capture the caller and stack trace when a trunk is deleted. If you prefer, start by sharing the code that implements the real SIP store’s delete/remove methods and any scheduled background tasks — I’ll point out likely suspects and exact lines to instrument. , with interactive elements