Asterisk AMI configuration update is missing, stale or wrong

Freeze the transaction and first divergence

Record branch and build, configuration directory, source and destination filenames, file hashes and owner, generator or management layer, manager identity and permissions, ActionID, every indexed operation, PreserveEffectiveContext, Reload, raw response and expected runtime effect.

Classify the first symptom: read returned the wrong scope, create failed, write rejected, wrong category changed, file changed but reload failed, runtime stayed stale, or runtime changed but service behavior did not.

Reconstruct the bounded read

Use ListCategories to retain category order and duplicates, then read the narrowest relevant category. Re-run with the intended filter and explicit template treatment. Compare the ordinary and JSON representations only at equivalent scope; GetConfigJSON is documented for rawman over HTTP.

If values appear absent, trace templates and includes before adding duplicates. A one-file response can be accurate and still omit inherited or included effective input.

Audit every indexed operation in order

Expand the six-digit Action-000000 sequence and pair each entry with its category, variable, value, match, line and options fields. Check that delete and insert line numbers were derived from the retained before-image and that a catfilter constrained duplicate categories when needed.

Separate DelCat from EmptyCat, Update from Append, and NewCat from RenameCat. A plausible final key can hide an unintended intermediate deletion or duplicate.

Compare source, destination and owner

Confirm which file was read and which was written; SrcFilename and DstFilename are separate fields. Read back the destination and compare its hash and bounded content with the approved model. If CreateConfig was used, verify that the empty file was expected and subsequently populated.

If another service generates the file, stop repeated AMI writes and repair the owning model. Otherwise the next regeneration can legitimately replace the apparent fix.

Trace templates, includes and reload

Record PreserveEffectiveContext and inspect whether inherited values were materialized or omitted as intended. Follow #include and #tryinclude paths to the file the target module actually reads. Do not infer effective runtime solely from the written destination.

Correlate the requested Reload value with module-specific logs and loaded objects. A general response is not proof that a named module supports reload or accepted every option.

Verify runtime and service outcome independently

Inspect the exact loaded endpoint, transport, queue, logger, dialplan object or other module state affected by the change, then run one authorized acceptance case and preserve signaling and media evidence appropriate to it. Roll back through the true owner if the first divergence remains.

Do not broaden AMI privileges, expose the manager port or disclose configuration secrets to make diagnosis easier. No PBX, module, manager session, configuration file, filesystem, reload, channel, packet, media stream or live call was inspected or tested for this diagnostic.

Check module registration after a correct file update

The module capability diagnostic continues from file and reload evidence through registered capabilities and exact runtime objects.