Prove that a Sorcery memory cache owns the object
Start with the responding node, installed Asterisk release, loaded res_sorcery_memory_cache module and effective sorcery.conf mapping. A cache mapping must precede the backing wizard it fronts, and its cache name is the control target. When no explicit name is provided, Asterisk documents a default derived from module and object type, such as res_pjsip/endpoint.
A database row, generated file, ARI-pushed object and cached runtime object are different evidence. Identify the authoritative backend and configuration owner before attempting to refresh anything; a cache action cannot repair an absent or invalid backend record.
Choose expire or stale by retrieval semantics
SorceryMemoryCacheExpireObject removes one object so the next lookup misses the cache and consults later mappings. SorceryMemoryCacheStaleObject leaves the stale value available; on retrieval, Asterisk returns that stale object and starts a background backend update. The optional Reload field on the object-stale action requests immediate backend reload instead of waiting for the next retrieval.
These are materially different consistency choices. An accepted stale action does not mean the caller immediately receives new data, while an accepted expire action does not prove the next backend read succeeded.
Reserve whole-cache controls for evidenced scope
SorceryMemoryCacheExpire removes every object from one named cache, and SorceryMemoryCacheStale marks every object in that cache stale. Both are broader than their object-scoped counterparts and can change backend traffic and timing for unrelated tenants or endpoints.
Use exact cache and object identity whenever possible. Retain node, manager identity, ActionID, action response, prior cache inventory and the reason a whole-cache operation was necessary. Do not turn a missing object name into permission for a fleet-wide flush.
Treat full-backend caching as a separate mode
With full_backend_cache=yes, Asterisk preloads the complete object set so multi-object retrievals can remain in memory. The current action reference says object-scoped expiry is unavailable in this mode. SorceryMemoryCachePopulate instead expires all cached entries and repopulates the cache from the backend; it is not a one-object refresh.
Preserve backend query completion, returned object count, cache count and errors separately. A successful AMI response does not prove that every database row was returned, parsed, committed to cache or safe for downstream use.
Keep timers, reloads and explicit controls distinct
object_lifetime_stale starts stale-while-refresh behavior after the configured age, while object_lifetime_maximum removes an object after its lifetime. The age is measured from insertion rather than last access. expire_on_reload determines whether a module reload clears that module's cache and is disabled by default in the documented guide.
A reload event reports module reload status; it does not by itself prove a particular cache was cleared, repopulated or read from the expected backend. Record the effective cache options and observe the exact object after the lifecycle event.
Verify effective behavior beyond cache state
After one authorized change, compare authoritative backend data, cache membership and age, a new lookup, the effective PJSIP or other Sorcery object and the first downstream decision that consumes it. Keep endpoint policy, AoR contacts, registration, identify selection, dialplan routing, call setup and media independent.
Limit AMI credentials and network access to the necessary action and event classes. Redact object data that contains credentials or personal information. No PBX, cache, database, manager action, packet, media stream or live call was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.