Asterisk AstDB key is missing, blank, stale or unexpectedly deleted

Freeze one key and one caller decision

Record timestamp and timezone, Asterisk version, dialplan revision, channel unique and linked IDs, context, extension and priority, exact family, exact key, DB_EXISTS() result, returned value, DB_RESULT, expected owner, last known update and final caller treatment. Redact sensitive values.

Classify the first divergence as unavailable function, wrong dialplan branch, different family or key, absent key, present blank value, invalid or stale value, concurrent update, destructive read, bulk deletion, reload or restart misunderstanding, restore gap, wrong node or downstream route failure.

Separate absence from an empty value

Read the entry with both DB_EXISTS(family/key) and DB(family/key) on the same running node. Asterisk documents that DB() returns blank for a missing key, while DB_EXISTS() returns 1 or 0 and sets DB_RESULT when the entry exists. Preserve those results before subsequent functions overwrite channel state.

Do not repair an absent key by guessing a default. Confirm whether absence is valid, whether a present blank value has a defined meaning and which generated or custom component owns creation.

Compare the exact namespace and producer

Compare case, slashes, prefixes, tenant or extension identifiers and normalized number format character by character. Use bounded CLI evidence such as database get or database showkey against the same Asterisk instance, and use DB_KEYS(prefix) only to inventory the intended subtree.

A similarly named key in another family, node, restored snapshot or managed-PBX namespace is different state. Do not move, copy or delete it until the owning module and expected value contract are known.

Reconstruct writes, destructive reads and races

Find every dialplan, module, CLI or supported management path that can write or remove the key. DB_DELETE() returns the previous value while deleting the entry; a call path using it as though it were a harmless read can explain a value that appears once and then vanishes. Check for DBdeltree or CLI subtree deletion separately.

For read-modify-write logic, correlate concurrent channels and confirm that all participants use the same local mutex around the complete sequence. A single successful write or lock result does not prove that a later writer did not replace the value.

Verify the node, restart and restore boundary

AstDB persistence across reloads and restarts applies to the database on the inspected Asterisk instance. Confirm the node, database path and process ownership through the supported platform before and after the event. Do not treat a value on one PBX as evidence that another node shares it.

Compare the backup scope and restore timestamp with the expected write. A restored configuration without the relevant AstDB state, or restored AstDB with a newer generated configuration, can create a consistent file set with an inconsistent application contract. Keep both artifacts under their supported platform owner.

Correct one owner and repeat bounded controls

Correct only the first demonstrated cause: key construction, creation branch, value validation, unauthorized deletion, missing local lock, wrong node, backup coverage or restore order. Preserve the prior state and a rollback. Do not edit the live SQLite file directly or clear an unfamiliar family to make the symptom disappear.

Repeat an absent-key control, a present blank value, a valid write and readback, one controlled concurrent update where applicable, and the intended reload or restart. Verify the final caller route separately from database state. No PBX, module, database file, key, value, dialplan, channel, backup, restore or call was inspected or tested for this diagnostic.

Identify the state owner before repairing a missing key

Use the HASH and ARRAY diagnostic when the disputed key belongs to dialplan HASH state rather than AstDB.

Trace the same key across the AMI boundary

The AMI AstDB diagnostic adds session, action-inventory, ActionID and tree-delete evidence.