Lead list work stalls on a database lock

Source and affected scope

MariaDB InnoDB lock wait views ↗

Source date

Not stated in source

Source checked

2026-11-07

Reported version

Version-specific behavior; inspect the installed release

Guide updated

2026-11-07

• Import or dialer activity appears blocked around lead-list tables.

Before you start

• Authorized read-only access on a test database; lock views may require PROCESS or other elevated diagnostic privileges.
• Confirm database engine and version; MariaDB sys.innodb_lock_waits is available from 10.6 and may differ on other products.

Diagnose the reported problem

1. Step 1Identify the engine and currently waiting transactions

   First inspect the table engine and server version. On supported MariaDB inspect the sys view; access may require a separately authorized DBA.

   Fictional example: waiting transaction 120 requests a lock held by 95 on a list-related InnoDB table. That identifies a current wait relationship, not why transaction 95 remains open.

   Before you use it

   Run only on an authorized isolated lab or approved read-only diagnostic session; substitute placeholders. Preserve sensitive data privately.

   SELECT VERSION();SHOW TABLE STATUS LIKE 'vicidial_list';SELECT * FROM sys.innodb_lock_waits;

   Reader-run example · not executed for this guide

   This example has no recorded result here. Follow its preparation, expected result and stop conditions before using it.

   Success looks like

   An actual waiting and blocking transaction and object are recorded together with time and owning connection where available.

   Stop if

   Empty output can mean no current wait or insufficient visibility, not proof that contention never happened. MyISAM and metadata locks need different diagnostics.

   Expected observation

   An actual waiting and blocking transaction and object are recorded together with time and owning connection where available.

   If this check fails

   Empty output can mean no current wait or insufficient visibility, not proof that contention never happened. MyISAM and metadata locks need different diagnostics.

2. Step 2Trace the blocking owner without interrupting it

   A DBA correlates the blocking connection with an approved process inventory and application job; restrict output because query text may contain customer data. Compare transaction age and wait timing with import and dialer activity.

   Expected observation

   The owner and workload of the actual blocker are identified.

   If this check fails

   If only metadata locks or a non-InnoDB table is involved, use version-specific diagnostics rather than applying this InnoDB view.

Correct the confirmed cause

Use this branch only when your diagnostic observations match the affected scope above. The lab result states which outcomes were actually tested.

1. Step 3Resolve through the workload owner

   Agree with the owner whether to let the transaction complete, safely cancel the source job or reschedule an import. Record the action and potential rollback; do not issue KILL, repair or optimize commands based only on this view.

   Expected observation

   The change is scoped to the identified workload and approved by its owner.

   If this check fails

   Stop if ownership or safe recovery is unknown.

Verify the outcome

• Recheck the same view and application queue over the same workload window; confirm the specific wait clears and list processing progresses without new errors.

Recover or roll back

• Restore the prior schedule or job configuration if the approved change worsens behavior; preserve the database and logs, and involve the DBA before any rollback of data.

Screenshot evidence

No native screenshot is attached to this guide.

• MariaDB InnoDB lock wait views · Primary documentation; checked 2026-11-07