@Rocky

{
  "Msg": "",
  "IndexId": "18434",
  "Warehouse": "default_warehouse",
  "OriginIndexId": "18434",
  "SchemaVersion": "1:0",
  "Timeout": "86400",
  "CreateTime": "2026-06-12 09:28:07",
  "TransactionId": "31495534",
  "IndexName": "WORKFLOW_EXECUTION",
  "TableName": "WORKFLOW_EXECUTION",
  "FinishTime": "2026-06-12 09:28:53",
  "State": "FINISHED_REWRITING",
  "JobId": "1061023"
}

one transaction is stuck in checked logs for this transaction id didnt found anything what can we check further routine load is not able to ingest

Based on the state

FINISHED_REWRITING

and the symptoms you described, your table is currently stuck in a Schema Change (ALTER TABLE) operation. In StarRocks,

FINISHED_REWRITING

means the data has been rewritten to the new schema format, but the job is waiting to "publish" the new version and swap the metadata. Because a schema change holds a metadata lock, it will block Routine Load and other ingestion tasks from committing. 1. Check for Metadata Locks The most likely reason the transaction is "stuck" is that it's waiting for a lock to finalize the schema change, or it's holding a lock that blocks others. Run this to see active locks:

sql
SELECT * FROM sys.fe_locks WHERE hold_time_ms > 10000;

Note: This requires

OPERATE

privileges and is available in newer versions (3.x+). 2. Verify Schema Change Status Check the detailed status of the alter job to see if there is an error message (

Msg

field) that wasn't in your snippet:

sql
SHOW ALTER TABLE COLUMN WHERE TableName = 'WORKFLOW_EXECUTION' \G

3. Check for Version Gaps (Shared-Data Mode) If you are using Shared-data mode (StarRocks 3.x Lake tables), a known issue exists where a schema change can hang in

FINISHED_REWRITING

if there is a "version discontinuity" (a missing version number in the sequence). Check your FE logs (

fe.log

) for errors like: *

partition.getVisibleVersion() + 1 != version.get(0)

*

readyToPublishVersion() requires commitVersion

4. How to resolve If the job is permanently stuck and blocking your Routine Load: * Attempt to Cancel: Try canceling the job using the

JobId

from your snippet.

sql
    CANCEL ALTER TABLE COLUMN FROM WORKFLOW_EXECUTION;

_Note: If the state is

FINISHED_REWRITING

, the system might say "Job cannot be cancelled."_ * Restart FE (Leader): If a metadata lock is orphaned, restarting the Leader FE node can sometimes force a cleanup of the lock manager state. * Clean up Transactions: Check if there are other extremely old running transactions that might be preventing this one from finishing:

sql
    SHOW PROC '/transactions/<db_id>'; -- Replace <db_id> with your DB's ID

What is your StarRocks version and cluster type (Shared-data or Shared-nothing)? Knowing this will help determine if you've hit a specific version bug. References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md

1. Check for Metadata Locks 0 locks 2. Verify Schema Change Status stuck on finished rewriting there is an transaction which is stuck btw @Rocky

If your StarRocks schema change is stuck in the

FINISHED_REWRITING

state and blocking Routine Load, it means the data transformation is complete on the Backends (BEs), but the Frontend (FE) cannot finalize the metadata (the "Publish" phase). This usually happens because a transaction is preventing the table version from advancing. Here is how to troubleshoot and resolve this: 1. Identify the Stuck Transaction The

TransactionId: 31495534

in your snippet is the transaction for the schema change itself. If it is stuck, there is likely an older transaction (with a smaller ID) that hasn't finished, blocking this one from becoming visible. Run these commands to find the blocker: 1. Get your Database ID:

sql
   SHOW PROC '/transactions';

2. Check for running transactions in that database (replace

<db_id>

):

sql
   SHOW PROC '/transactions/<db_id>/running';

* What to look for: Look for any transactions with a smaller ID than

31495534

. If an older transaction is stuck in

PREPARE

or

COMMITTED

but not

VISIBLE

, it will block your schema change from finishing. 2. Check for Version Gaps (Shared-data/Lake Tables) If you are using StarRocks 3.x with Shared-data mode, there is a known issue where a "version discontinuity" can happen. Check your FE leader's

fe.log

for this specific error:

partition.getVisibleVersion() + 1 != version.get(0)

If you see this, the version sequence is broken (e.g., the table is at version 100, and the system is trying to publish version 102, but version 101 is missing). This requires a manual metadata fix or a specific patch depending on your version. 3. Check Routine Load Tasks Since Routine Load is failing, it might be the victim (blocked by the schema change lock) or the cause (an old task holding a version open). * Check the status of current tasks:

sql
    SHOW ROUTINE LOAD TASK WHERE JobName = 'your_job_name';

* If you see tasks in

COMMITTED

state for a long time, they are waiting for the schema change to finish. 4. Recommended Actions 1. Kill long-running queries/transactions: If you find an old transaction in

SHOW PROC '/transactions/<db_id>/running'

, try to identify its source (e.g., a hung Stream Load or Insert) and stop it. 2. Restart the FE Leader: If the FE is in a deadlock state or an internal metadata lock is orphaned, restarting the Leader FE node often triggers a cleanup and allows the

FINISHED_REWRITING

job to finally move to

FINISHED

. 3. Check for Disk/IO issues: Ensure your BEs are not under extreme disk pressure, as the final "move" of data files can hang if the filesystem is unresponsive. Can you confirm: 1. Are you using Shared-data (Cloud-native) or Shared-nothing? 2. Did you find any transactions with an ID smaller than 31495534 in the

running

list`running` list? ` list? References • sql-reference/sql-statements/cluster-management/nodes_processes/SHOW_PROC.md • sql-reference/sql-statements/loading_unloading/routine_load/SHOW_ROUTINE_LOAD_TASK.md • sql-reference/sql-statements/loading_unloading/routine_load/SHOW_ROUTINE_LOAD.md