tp_shell List Updates Not Reflected in <code>listTable.listConditionBlob</code> Until MGR GUI “Save” (Release 22.12)

Solution

Problem Summary

Symptom (no explicit error message): After running tp_shell to add MSISDNs to a list (with explicit list id/index1 and item index/index2), the entries appear in the MGR GUI, but do not appear in MySQL when querying mgr_domain_main.listTable.listConditionBlob until clicking Save in the MGR GUI.

Operational impact: Automations that compute the “next index” from database extracts can reuse an old index if they rely on listConditionBlob (because the blob may appear unchanged until GUI Save).

Environment

• Version: Release 22.12 (R04.22.12.00)

How to Recognize This Specific Mismatch

You are likely validating against the consolidated blob representation instead of the row-based table:

• mgr_domain_main.listTable.listConditionBlob may not change after tp_shell.
• mgr_domain_main.listConditionTable does show the new entries after tp_shell.

A reliable indicator is that deterministic checks like LENGTH(), MD5(), or LOCATE() remain unchanged after tp_shell, but change after a GUI Save:

SELECT LENGTH(listConditionBlob) AS len, MD5(listConditionBlob) AS md5
FROM listTable
WHERE listname = '<list_name>';

SELECT LOCATE('<msisdn_plain_digits>', listConditionBlob) AS pos_value
FROM listTable
WHERE listname = '<list_name>';

Root Cause

Two different database representations are involved:

• Row-based storage (authoritative for tp_shell-driven inserts)
  mgr_domain_main.listConditionTable
  • listConditionIndex1 = list identifier (list id)
  • listConditionIndex2 = item index/sequence
  • listCondition = value (for example, MSISDN string)
• Consolidated/serialized representation (may refresh later)
  mgr_domain_main.listTable.listConditionBlob
  

  This is a single “blob” representation of the list’s full content and may not be regenerated immediately. In the captured evidence, it refreshed only after a GUI Save.

Recommended Validation + Automation Pattern

1) Validate inserts in the correct DB table (listConditionTable)

After running tp_shell add commands, verify the new values and indexes directly:

USE mgr_domain_main;

-- Get the next index for automation
SELECT MAX(listConditionIndex2) AS max_idx
FROM listConditionTable
WHERE listConditionIndex1 = <list_id>;

-- Confirm specific inserted entries exist
SELECT listConditionIndex2, listCondition
FROM listConditionTable
WHERE listConditionIndex1 = <list_id>
  AND listCondition IN ('<msisdn_1>','<msisdn_2>','<msisdn_3>');

Operational note: Use MAX(listConditionIndex2) from listConditionTable as the source of truth for computing the next indexes in CLI automation. Do not derive “next index” from listConditionBlob.

2) Validate runtime/enforcement on FW/RTR nodes (distribution check)

To confirm the list is active at runtime and rules referencing the list will apply, validate on a FW/RTR node:

• Run tp_walk listcondition or tp_walkall on the FW/RTR node.
• Confirm:
  • The entry count increased as expected.
  • The new listCondition.<list_id>.<item_index> entries exist.

3) When (and why) to use MGR GUI “Save”

Use GUI Save if:

• You have a reporting/export/integration that reads list contents specifically from listTable.listConditionBlob, or
• You need the consolidated blob representation to refresh.

If you do not click Save for long periods:

• Runtime enforcement can still be validated via FW/RTR tp_walkall and the row-based DB table listConditionTable.
• Workflows that depend on listConditionBlob may appear “out of sync” until Save is performed.

4) Avoid conflicts when later editing/removing entries in GUI

If you plan to remove entries using the GUI:

1. Reopen/refresh the list view first so the GUI reflects the latest state.
2. Remove the desired entry.
3. Click Save.

This reduces the risk of saving an older/stale view of the list.