http://starrocks.io logo
Join Slack
Powered by
<@U0A71G31CDV> i am trying to use the transactiona...
# questions-and-troubleshooting
c
@Rocky i am trying to use the transactional stream load interface, but i am getting de following error: [2026-07-15 103111.008 -0300] ERROR: StarRocks upsert failed {“context”:“ProcessorService”} err: { “type”: “Error”, “message”: “Transaction commit failed (label=cdc-1784122267332-33c75f5a): [FAILED] STREAM_LOAD_TASK:1442043, label{cdc-1784122267332-33c75f5a}, error_msg{cancel stream task for exception: No rows were imported from upstream. Possible causes: 1) all rows were filtered by load conditions, 2) all rows failed data quality/validation checks, or 3) upstream has no data. If this is acceptable, set 
ADMIN SET FRONTEND CONFIG (‘empty_load_as_error’ = ‘false’)
to ignore empty loads}“, “stack”: Error: Transaction commit failed (label=cdc-1784122267332-33c75f5a): [FAILED] STREAM_LOAD_TASK:1442043, label{cdc-1784122267332-33c75f5a}, error_msg{cancel stream task for exception: No rows were imported from upstream. Possible causes: 1) all rows were filtered by load conditions, 2) all rows faileddata quality/validation checks, or 3) upstream has no data. If this is acceptable, set 
ADMIN SET FRONTEND CONFIG (‘empty_load_as_error’ = ‘false’)
to ignore empty loads} at StarRocksService.commitTransaction (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/starrocks/starrocks.service.ts34913) at processTicksAndRejections (nodeinternal/process/task queues95:5) at StarRocksService.upsertBatch (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/starrocks/starrocks.service.ts1417) at ProcessorService.processBatch (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/processor/processor.service.ts17726) at CdcSqsHandlerService.doFlush (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/sqs/cdc-sqs-handler.service.ts11520) }
r
The error "No rows were imported from upstream" occurs when a Stream Load (or Transactional Stream Load) job completes without successfully writing any data to the destination table. This usually happens for one of the following reasons: 1. Root Causes * Empty Batch: You called 
/api/transaction/load
with an empty file or a stream that contained no data. * Data Quality/Validation Failures: All rows in your batch failed the data type validation (e.g., trying to load a string into an INT column) or failed "strict mode" checks. * Filter Conditions: All rows were filtered out by a 
WHERE
clause or 
max_filter_ratio
logic. * Format Mismatch: If your 
column_separator
or 
row_delimiter
is incorrect, StarRocks might fail to parse any rows correctly, treating them as invalid and filtering them all out. 2. Immediate Solutions A. If empty loads are expected (The "Quick Fix") If your CDC logic occasionally sends empty batches and you want StarRocks to treat this as a success rather than an error, you can change the global FE configuration:
Copy code
sql
ADMIN SET FRONTEND CONFIG ('empty_load_as_error' = 'false');
Default is 
true
. When set to 
false
, an empty load will return a "Success" status with 0 rows loaded. B. Debugging Data Quality If you expected data to be loaded, you need to find out why the rows were filtered. 1. Check the 
/api/transaction/load
response: Before calling 
commit
, look at the JSON response from your 
load
call. Check these fields: * `NumberTotalRows`: How many rows StarRocks tried to read. * `NumberFilteredRows`: How many rows failed due to data quality. 2. Check the Error URL: If 
NumberFilteredRows > 0
, the response will usually contain an 
ErrorURL
. Open this URL in a browser or use 
curl
to see the specific reason each row was rejected (e.g., "column count mismatch" or "invalid data type"). 3. Verify Separators: If you are loading CSV data, ensure your headers include the correct 
-H "column_separator:..."
and 
-H "row_delimiter:..."
. The default is 
\t
(tab) and 
\n
. 3. Recommendation for CDC Workloads In CDC scenarios, it is common to have batches that result in no changes (e.g., all rows filtered by logic). In such cases: * Set 
empty_load_as_error
to 
false
 to avoid crashing your worker. * Check the 
NumberFilteredRows
 in your application code. If this number is greater than 0, log the 
ErrorURL
so you can identify if your upstream schema has drifted from your StarRocks schema. References • loading/loading_introduction/troubleshooting_loading.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md
c
@Rocky i dont have filtered rows: [2026-07-15 105620.019 -0300] INFO: Transaction load response {“context”“StarRocksService”,“Status”“OK”,“Message”“”,“Db”“treinta”,“Table”“transactions stats”,“Label”“cdc-1784123780003-ccd8f64d”,“TxnId”94203,“LoadBytes”425,“StreamLoadPlanTimeMs”0,“ReceivedDataTimeMs”0}
r
The log you provided shows that 
LoadBytes
is 425, but the response is missing the 
NumberLoadedRows
and 
NumberTotalRows
fields that usually appear in a successful row-processing response. When 
LoadBytes > 0
but StarRocks still reports "No rows were imported," it typically means one of the following: 1. The Parser found no valid Rows (Delimiter Mismatch) This is the most common reason. StarRocks successfully received 425 bytes of data, but because the 
column_separator
or 
row_delimiter
did not match your data, the parser could not find a single valid record. * Example: If your data is CSV (comma-separated) but you didn't specify 
-H "column_separator:,"
, StarRocks defaults to 
\t
(Tab). It will read the entire 425 bytes as one single "column," find it doesn't match your table schema, and discard it. * Fix: Explicitly set the separators in your 
/api/transaction/load
headers:
Copy code
bash
    -H "column_separator:,"
    -H "row_delimiter:\n"
2. JSON Format Issues If you are sending JSON data: * Ensure you are sending the header 
-H "format:json"
. * If your JSON is an array of objects, you must also send 
-H "strip_outer_array:true"
. * Without these, StarRocks may read the bytes but fail to map them to any rows, resulting in 0 rows being parsed. 3. All rows were "Unselected" (WHERE clause) Check if your load request includes a 
where
parameter. * If your load command has 
-H "where: <condition>"
, and that condition evaluates to 
false
for every single row in those 425 bytes, 
NumberLoadedRows
will be 0. * In your log, look for 
NumberUnselectedRows
. If it's present and equals the total rows, your 
WHERE
clause is too restrictive. 4. Empty lines or Header interference * If your file contains only a header line and you have set 
ignore_group_lines
, or if the file contains only whitespace/newlines, 
LoadBytes
will be > 0 but 
NumberLoadedRows
will be 0. How to debug this specifically: Since your 
load
response returned 
Status: OK
, the transaction is still "open" but "empty." To see exactly what happened to those 425 bytes: 1. Check the full JSON response of the 
/api/transaction/load
call. Look for: * 
NumberTotalRows
* 
NumberFilteredRows
* 
NumberUnselectedRows
2. If 
NumberTotalRows
is 0, your separators are likely wrong (the parser never found a row). 3. If 
NumberTotalRows
is
0
 but 
NumberLoadedRows
is 0, check if 
NumberUnselectedRows
is high (check your 
WHERE
clause) or if 
NumberFilteredRows
is high (check your 
ErrorURL
). Recommendation: If you are sure the data is correct and this "empty" state is a valid edge case for your CDC logic, you should apply the configuration mentioned before to allow the 
commit
to succeed:
Copy code
sql
ADMIN SET FRONTEND CONFIG ('empty_load_as_error' = 'false');
References • loading/Stream_Load_transaction_interface.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md
c
@Rocky this is my log: [2026-07-15 105909.397 -0300] DEBUG: incoming tables {“context”“ProcessorService”,“tables”{“transactions”:1}} [2026-07-15 105909.399 -0300] INFO: ETL batch {“context”“ProcessorService”,“transformed”1,“failed”:0} [2026-07-15 105909.399 -0300] DEBUG: upsertBatch start {“context”“StarRocksService”,“count”1} [2026-07-15 105909.399 -0300] DEBUG: beginTransaction {“context”“StarRocksService”,“headers”{“db”“treinta”,“label”“cdc-1784123949399-5e5e4aa2",“transaction_type”:“multi”}} [2026-07-15 105909.404 -0300] INFO: Transaction begin response {“context”“StarRocksService”,“label”“cdc-1784123949399-5e5e4aa2",“result”{“Status”“OK”,“Message”:“”}} [2026-07-15 105909.404 -0300] INFO: Transaction begun {“context”“StarRocksService”,“label”“cdc-1784123949399-5e5e4aa2”} [2026-07-15 105909.404 -0300] INFO: processing table upserts and deletes (table:transactions_stats) (label=cdc-1784123949399-5e5e4aa2) {“context”“StarRocksService”,“table”“transactions_stats”,“upserts”1,“deletes”0} [2026-07-15 105909.404 -0300] DEBUG: transaction load PUT {“context”“StarRocksService”,“url”“localhost/api/transaction/load”,“label”“cdc 1784123949399 5e5e4aa2”,“table”“transactions_stats”,“body_bytes”834,“headers”{“Content-Type”“application/json”,“transaction type”“multi”,“format”“json”,“strip outer array”“false”,“Expect”“100 continue”,“db”“treinta”,“table”“transactions stats”,“label”“cdc-1784123949399-5e5e4aa2”,“merge_condition”:“version”}} [2026-07-15 105909.410 -0300] DEBUG: put 307 redirect {“context”“StarRocksService”,“url”“localhost/api/transaction/load”,“location”:“starrocks-be/api/transaction/load”} [2026-07-15 105909.413 -0300] INFO: Transaction load response {“context”“StarRocksService”,“Status”“OK”,“Message”“”,“Db”“treinta”,“Table”“transactions stats”,“Label”“cdc-1784123949399-5e5e4aa2”,“TxnId”94213,“LoadBytes”834,“StreamLoadPlanTimeMs”0,“ReceivedDataTimeMs”0} [2026-07-15 105909.413 -0300] DEBUG: Transaction load staged {“context”“StarRocksService”,“table”“transactions_stats”,“label”“cdc 1784123949399 5e5e4aa2”,“duration ms”9} [2026-07-15 105909.420 -0300] INFO: Transaction rolled back {“context”“StarRocksService”,“label”“cdc-1784123949399-5e5e4aa2"} [2026-07-15 105909.420 -0300] ERROR: StarRocks upsert failed {“context”:“ProcessorService”} err: { “type”: “Error”, “message”: “Transaction commit failed (label=cdc-1784123949399-5e5e4aa2): [FAILED] STREAM_LOAD_TASK:349922, label{cdc-1784123949399-5e5e4aa2}, error_msg{cancel stream task for exception: No rows were imported from upstream. Possible causes: 1) all rows were filtered by load conditions, 2) all rows failed data quality/validation checks, or 3) upstream has no data. If this is acceptable, set 
ADMIN SET FRONTEND CONFIG (‘empty_load_as_error’ = ‘false’)
to ignore empty loads}“, “stack”: Error: Transaction commit failed (label=cdc-1784123949399-5e5e4aa2): [FAILED] STREAM_LOAD_TASK:349922, label{cdc-1784123949399-5e5e4aa2}, error_msg{cancel stream task for exception: No rows were imported from upstream. Possible causes: 1) all rows were filtered by load conditions, 2) all rows failed data quality/validation checks, or 3) upstream has no data. If this is acceptable, set 
ADMIN SET FRONTEND CONFIG (‘empty_load_as_error’ = ‘false’)
to ignore empty loads} at StarRocksService.commitTransaction (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/starrocks/starrocks.service.ts34713) at processTicksAndRejections (nodeinternal/process/task queues95:5) at StarRocksService.upsertBatch (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/starrocks/starrocks.service.ts1417) at ProcessorService.processBatch (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/processor/processor.service.ts17726) at CdcSqsHandlerService.doFlush (/Users/taity/Work/sanbox/treinta-cdc-starrocks-worker/src/sqs/cdc-sqs-handler.service.ts11520) } [2026-07-15 105909.421 -0300] INFO: flush completed {“context”“CdcSqsHandlerService”,“flushed”1,“acked”0,“retry”1}
r
Based on your logs, the system received 834 bytes (
LoadBytes
), but during the 
commit
phase, it reported that 0 rows were actually imported. Since you are sending JSON data (
format: json
), this usually happens because the parser could not map the JSON fields to your table columns, or the JSON structure didn't match your settings. 1. The 
strip_outer_array
Mismatch This is the most frequent cause. * If your data is a JSON Array like `[{"id": 1}, {"id": 2}]`: * You must set 
-H "strip_outer_array: true"
. _ In your logs, it is currently set to 
false
. With 
false
, StarRocks tries to treat the entire array as a _single row*, which usually fails validation and results in 0 rows loaded. * If your data is a single JSON Object like `{"id": 1}`: * 
strip_outer_array: false
is correct. 2. Missing or Incorrect 
jsonpaths
 If your JSON keys do not exactly match your StarRocks table column names (including case sensitivity), StarRocks will see those fields as "missing." * If all fields in the JSON are ignored because they don't match table columns, the row becomes "empty" and is filtered out. * Solution: If the keys don't match exactly, add the 
jsonpaths
header to explicitly map them:
Copy code
bash
    -H "jsonpaths: [\"$.json_key1\", \"$.json_key2\"]"
    -H "columns: column1, column2"
3. The 
merge_condition
(Primary Key Tables) Your logs show 
-H "merge_condition: version"
. This is used for Primary Key tables to handle out-of-order data. * The Problem: If the 
version
field in your JSON is 
null
, missing, or has a value less than or equal to the version already stored in StarRocks for that Primary Key, the row will be silently ignored or "filtered" to prevent overwriting newer data. * Verification: Ensure every record in your 834-byte payload contains a valid, incrementing 
version
value. 4. How to find the specific error (The "ErrorURL") In a standard Stream Load, the response contains an 
ErrorURL
. In a Transactional Stream Load, you might need to check the FE/BE logs or use the following SQL to find the reason for the failure:
Copy code
sql
-- Replace with the label from your log
SHOW LOAD WHERE label = 'cdc-1784123949399-5e5e4aa2';
Look for the 
ErrorMsg
or 
ErrorURL
column in the result. The 
ErrorURL
will show you exactly why the rows were rejected (e.g., "column count mismatch" or "parsing error"). Summary Checklist 1. Check JSON format: If you're sending 
[...]
, set 
strip_outer_array: true
. 2. Verify Column Names: Ensure JSON keys match table column names exactly. 3. Check `version`: Ensure the 
version
column exists in your JSON and is populated with a valid value. 4. Set `empty_load_as_error`: If your CDC occasionally produces empty batches, run:
Copy code
sql
    ADMIN SET FRONTEND CONFIG ('empty_load_as_error' = 'false');
References • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • sql-reference/sql-statements/loading_unloading/BROKER_LOAD.md • sql-reference/sql-statements/loading_unloading/routine_load/CREATE_ROUTINE_LOAD.md • faq/loading/Routine_load_faq.md • loading/Json_loading.md • loading/StreamLoad.md
c
@Rocky this is my data: { internal_id: ‘1016123958008284866’, internal_store_id: ‘3853049300414731940’, internal_user_id: ‘-3547821674747622272’, internal_contact_id: null, id: ‘0006275d-0660-4828-a9da-1c997ede3578’, uid: null, store_id: ‘31303931-3733-5463-b866-343438633638’, user_id: ‘35653137-3538-5837-b765-646538313836’, contact_id: null, date: ‘2025-04-27 180109’, value: 3500, payment_type_id: 1, transaction_status_id: 1, transaction_type_id: 1, origin_id: 4, delivery_type_id: null, spend_category_id: null, transaction_count: 492, is_offline: 0, delivery_price: null, last_reminder: null, payments_data: null, order_address: null, created_at: ‘2025-07-07 180110’, updated_at: ‘2026-07-15 135907’, deleted_at: null, version: 1784123947000, event_type: ‘update’, source_timestamp: ‘2026-07-15 135907’, event_timestamp: ‘2026-07-15 140209’ }
r
The reason for the error is that while StarRocks received 834 bytes, it was unable to find any valid rows within those bytes. Looking at the data you provided, there are two likely causes: 1. Invalid JSON Format (Most Likely) The data snippet you shared is a JavaScript Object, not a JSON String. * Unquoted Keys: In JSON, keys must be double-quoted (e.g., 
"internal_id"
, not 
internal_id
). * Single/Smart Quotes: JSON requires standard double quotes (
"
) for strings. Your snippet uses single quotes (
'
) or "smart" quotes (
‘...’
). * Trailing Commas: Standard JSON does not allow trailing commas. If your code is sending the literal string representation of that JS object (e.g., via 
object.toString()
), the StarRocks JSON parser will fail to find a single valid record. The Fix: Ensure your application is sending a valid JSON string using `JSON.stringify(data)`:
Copy code
javascript
// In your StarRocksService
const body = JSON.stringify(dataBatch); // This produces valid JSON
2. The 
strip_outer_array
Header In your logs, you have 
-H "strip_outer_array: false"
. * If you are sending an Array of objects (e.g., 
[{...}, {...}]
), you must set this to 
true
. * If you set it to 
false
and send an array, StarRocks tries to parse the entire array as one single row, which will fail because the array structure doesn't match your table columns. 3. Case Sensitivity & Column Mapping StarRocks column names are case-sensitive. Ensure the keys in your JSON (like 
internal_id
) match the column names in your 
transactions_stats
table exactly. * If your table column is 
Internal_Id
(capitalized) but your JSON is 
internal_id
, the parser will see a "missing" column. * If all columns are missing/null, the row may be filtered out. 4. Primary Key & 
merge_condition
 You are using 
-H "merge_condition: version"
. * If StarRocks already has a row with the same Primary Key and a 
version
value greater than or equal to 
1784123947000
, the new row will be ignored. * However, usually, this would result in the row being "processed" but not "updated." If the result is "No rows imported," it points back to a parsing error (Cause #1). How to verify the specific parsing error Run the following SQL in your StarRocks console to see the exact reason why the rows were rejected for that specific label:
Copy code
sql
SHOW LOAD WHERE label = 'cdc-1784123949399-5e5e4aa2';
Look at the 
ErrorMsg
column. If it is empty, look for the 
ErrorURL
. Opening that URL will show you the exact parsing error (e.g., 
[PARSE_ERROR] unexpected character...
). Recommendation: 1. Check that your body is being sent as a valid JSON string (
JSON.stringify
). 2. If you are sending an array of records, change 
strip_outer_array
to 
true
. 3. Execute 
ADMIN SET FRONTEND CONFIG ('empty_load_as_error' = 'false');
to prevent your worker from crashing on empty batches. References • loading/Json_loading.md • loading/Flink_cdc_load.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • loading/loading_introduction/feature-support-loading-and-unloading.md
c
@Rocky how can i debug this load task “message”: “Transaction commit failed (label=cdc-1784124467425-f1a23ea3): [FAILED] STREAM_LOAD_TASK:350069, label{cdc-1784124467425-f1a23ea3}, error_msg{cancel stream task for exception: No rows were imported from upstream. Possible causes: 1) all rows were filtered by load conditions, 2) all rows failed data quality/validation checks, or 3) upstream has no data. If this is acceptable, set 
ADMIN SET FRONTEND CONFIG (‘empty_load_as_error’ = ‘false’)
to ignore empty loads}“,
r
To debug a failed Stream Load transaction where "No rows were imported," follow these steps to find the specific parsing or data quality error. 1. Check for the 
ErrorURL
using SQL Even though your application log didn't show it, StarRocks records the error details for every load label. Run this in your MySQL client:
Copy code
sql
SHOW LOAD WHERE Label = 'cdc-1784124467425-f1a23ea3'\G
* Look for the 
ErrorMsg
column: It might give a hint like 
[PARSE_ERROR]
. * Look for the 
ErrorURL
column: If this column contains a URL, copy it and open it in your browser (or use 
curl
). It will contain the exact rows that failed and the specific reason (e.g., "column count mismatch" or "invalid JSON path"). 2. Query the 
information_schema.loads
table If 
SHOW LOAD
doesn't give enough detail, you can query the system metadata:
Copy code
sql
SELECT * FROM information_schema.loads 
WHERE label = 'cdc-1784124467425-f1a23ea3' 
ORDER BY create_time DESC;
3. Check BE (Backend) Logs Since the parsing happens on the Backend, the 
<http://be.INFO|be.INFO>
or 
be.WARNING
logs will contain the details of why the 834 bytes of data resulted in 0 rows. 1. Log into the BE node (in your logs, it's 
starrocks-be
). 2. Search the logs for the transaction ID or the label:
Copy code
bash
    grep "cdc-1784124467425-f1a23ea3" storage/log/be.INFO
You will likely see a message like 
JSON parse error
or 
all rows are filtered
. 4. Enable and Check the Load Profile If you want to see exactly how the data is being processed in real-time, enable the profile for your table:
Copy code
sql
-- Enable profile for the table
ALTER TABLE transactions_stats SET('enable_load_profile' = 'true');

-- After running your load again, check the profile list
SHOW PROFILELIST;

-- Get the details for the specific Query ID found in the list
ANALYZE PROFILE FROM 'your-query-id';
────────── Why it's failing (Root Cause from your data) The data you provided is not valid JSON.
Copy code
javascript
// This is a JavaScript Object, not JSON
{ internal_id: ‘1016...’, ... }
StarRocks requires strict JSON format: 1. Keys must be double-quoted: 
"internal_id"
, not 
internal_id
. 2. Strings must be double-quoted: 
"2025-04-27..."
, not 
‘2025-04-27...’
. 3. No trailing commas. How to fix it in your code: Ensure your application is sending the result of 
JSON.stringify(yourObject)
. If you are using a tool like 
curl
to test, ensure the file content looks like this:
Copy code
json
{"internal_id": "1016123958008284866", "internal_store_id": "3853049300414731940", ...}
Summary of fixes * If you send an array `[...]`: You must add the header 
"strip_outer_array: true"
. * If you send a single object `{...}`: Keep 
"strip_outer_array: false"
. * Always ensure the payload is a valid JSON string with double quotes. References • faq/loading/Stream_load_faq.md • loading/loading_introduction/troubleshooting_loading.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md
c
@Rocky SHOW LOAD returns an empty result set
r
If 
SHOW LOAD
returns an empty result set, it is usually because of one of the following reasons: 1. Database Context 
SHOW LOAD
only looks at the database you are currently using. Since your logs show the database is 
treinta
, you must switch to it first:
Copy code
sql
USE treinta;
SHOW LOAD WHERE Label = 'cdc-1784124467425-f1a23ea3';
Or use the explicit syntax:
Copy code
sql
SHOW LOAD FROM treinta WHERE Label = 'cdc-1784124467425-f1a23ea3';
2. Check the 
information_schema.loads
System View For Transactional Stream Loads (the multi-table API you are using), the data is often more easily found in the system views. This table contains records for Stream Loads that might not appear in the standard 
SHOW LOAD
if they were aborted early:
Copy code
sql
SELECT * FROM information_schema.loads 
WHERE LABEL = 'cdc-1784124467425-f1a23ea3' 
ORDER BY CREATE_TIME DESC;
Check the 
REASON
or 
ERROR_MSG
columns here. 3. Check the Transaction Status Since you are using the Transactional API (
/api/transaction/load
), the load is tied to a specific Transaction ID. You can find the history of the transaction itself:
Copy code
sql
-- You can find the TxnId from your logs (it was 94213 in your first log example)
SHOW TRANSACTION FROM treinta WHERE Id = 94213;
4. Locate the BE Error Logs (The "Source of Truth") If the SQL commands above return nothing, it means the FE (Frontend) rejected the request before it could even register the load task metadata, or the BE (Backend) encountered a parsing error so severe it couldn't report back. Since your log shows a 307 Redirect to 
starrocks-be:8040
, the parsing is happening on that specific Backend node. 1. Log into the machine/container running starrocks-be. 2. Go to the storage log directory (usually 
storage/log/
). 3. Run this command to find the specific reason for the "No rows imported" error:
Copy code
bash
   grep "cdc-1784124467425-f1a23ea3" <http://be.INFO|be.INFO>
Look for strings like: * 
[PARSE_ERROR]
* 
all rows are filtered
* 
JSON group not found
Most Likely Cause: JSON Parsing Given the data you provided earlier, the error is almost certainly that your data is not valid JSON. * Current Data: 
{ internal_id: ‘1016...’, ... }
(Invalid: single quotes, unquoted keys). * Required Data: 
{"internal_id": "1016...", ...}
(Valid JSON). If you are using the StarRocks Node.js or Java SDK, ensure you are using a JSON serializer (like 
JSON.stringify()
) and not just sending the object's string representation. References • loading/loading_introduction/troubleshooting_loading.md
c
@Rocky ok now i am seeing the load, is it correct the load type is :PARALLEL_STREAM_LOAD?
@Rocky commit failed: waitCoordFinish failed ?
r
The error "commit failed: waitCoordFinish failed" occurs during the transaction commit phase. It means the Frontend (FE) tried to finalize the transaction, but the Coordinator BE (the backend node responsible for managing your data stream) failed to report that it successfully finished processing the data. This is almost always a secondary error caused by the "No rows were imported" issue we identified earlier. Why this is happening 1. Empty/Failed Data Stream: You called 
/api/transaction/load
, but as we saw, 0 rows were actually parsed because of the JSON format issues (single quotes, unquoted keys). 2. State Mismatch: When you call 
/api/transaction/commit
, the FE asks the Coordinator BE, "Are you done with the data I sent you?" 3. The Failure: Because the BE encountered parsing errors or didn't receive any valid data during the load phase, it cannot "finish" the coordination correctly for that transaction label, leading to the 
waitCoordFinish failed
message. How to Resolve It 1. Fix the Root Cause (The Data Format) You must ensure the data you are sending in the 
load
step is valid JSON. The 
waitCoordFinish
error will disappear once the BE successfully processes at least one row. * Use double quotes for all keys and string values. * Use 
JSON.stringify(data)
 in your code rather than sending a raw object or a single-quoted string. 2. Check for BE-side crashes If your data format is correct and you still see this, it could mean the BE node crashed or timed out while trying to flush the data to disk. * Check the BE status: 
SHOW BACKENDS;
(Ensure 
Alive
is 
true
). * Check BE logs (
<http://be.INFO|be.INFO>
) for any 
Segmentation Fault
or 
Out of Memory
(OOM) errors during the commit time. 3. Adjust Timeouts (If the data is very large) If you are sending a very large amount of data in one transaction, the Coordinator might take longer than the default timeout to finish. * Increase the 
streaming_load_max_mb
(BE config) if you are near 10GB. * Increase the 
stream_load_default_timeout_second
(FE config) if the load takes more than 600 seconds. Summary for your specific case: The transaction is failing because the load phase failed (0 rows). You cannot successfully commit a transaction that has no valid data or encountered fatal parsing errors during the streaming phase. Action: Fix the JSON stringification in your application, then retry the 
begin
-> 
load
-> 
commit
flow. References • loading/Stream_Load_transaction_interface.md • faq/loading/Loading_faq.md • loading/loading_introduction/troubleshooting_loading.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md References • loading/Stream_Load_transaction_interface.md • loading/StreamLoad.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md
c
@Rocky at error_tracking_logs table i am seeing : Failed to access err: Internal error: URL rejected: Malformed input to a URL function be/src/exec/schema_scanner/schema_load_tracking_logs_scanner.cpp:141 client->execute(&tracking_msg)
r
The error 
Internal error: URL rejected: Malformed input to a URL function
inside the 
load_tracking_logs
scanner indicates that StarRocks is trying to fetch the detailed error report from a Backend (BE) node, but the internal URL it constructed for that request is invalid. This is a known issue in some versions (around v3.2.x - v4.0) when querying 
information_schema.load_tracking_logs
. It usually happens if the BE cannot correctly resolve the hostname of the node where the error log is stored, or if the 
ErrorURL
metadata contains characters that the internal HTTP client rejects. To get the actual load error details while this system view is failing, use these alternative methods: 1. Get the URL from 
information_schema.loads
 The 
load_tracking_logs
view is just a wrapper. You can get the raw URL and access it directly:
Copy code
sql
SELECT LABEL, REJECTED_RECORD_PATH 
FROM information_schema.loads 
WHERE LABEL = 'cdc-1784124467425-f1a23ea3';
If 
REJECTED_RECORD_PATH
is not null, copy that URL and run a 
curl
command from your terminal:
Copy code
bash
curl "http://<be_ip>:8040/api/_load_error_log?file=error_log_..."
2. Check the Backend Filesystem Directly If the URL is malformed or unreachable, you can find the raw error logs on the disk of the BE node that processed the load: 1. Log into your BE node(s). 2. Navigate to the storage directory (check your 
be.conf
for 
storage_root_path
). 3. Look into the 
error_log
directory:
Copy code
bash
   cd /path/to/storage/error_log/
   ls -ltr
4. Find the file matching the timestamp or label of your failed load. These files contain the specific rows that failed and the reason for the failure (e.g., "JSON parse error"). 3. Check BE Configuration The "Malformed URL" error often stems from hostname resolution issues between StarRocks nodes. * Check Hostnames: Run 
SHOW BACKENDS;
and ensure the 
IP
or 
Hostname
listed is reachable from all other nodes. * Force IP Addresses (v4.0.1+): If you are on a very recent version, you can try setting this BE configuration to force the use of IPs in error URLs:
Copy code
sql
  -- This is a BE dynamic configuration
  ADMIN SET FRONTEND CONFIG ('enable_resolve_hostname_to_ip_in_load_error_url' = 'true');
Why this is happening to your load The "No rows were imported" error you saw previously, combined with this "Malformed URL" error, strongly suggests that your data is not valid JSON. * When StarRocks fails to parse the very first record (e.g., because of the single quotes 
'
or unquoted keys you showed earlier), it attempts to write a tracking log. * If the tracking log system itself is hitting a bug/URL issue, you get this secondary error. Immediate Fix: Ensure your load data is strictly formatted JSON (using double quotes 
"
) and try the load again. This will likely bypass the need to check the error logs entirely. References • sql-reference/information_schema/load_tracking_logs.md • administration/management/BE_configuration.md • loading/loading_introduction/troubleshooting_loading.md • administration/management/monitoring/metrics.md • sql-reference/information_schema/loads.md
Yes, seeing the load type as 
PARALLEL_STREAM_LOAD
is correct if you have enabled the Parallel Stream Load feature. What is PARALLEL_STREAM_LOAD? Starting from StarRocks v3.0, the "Parallel Stream Load" feature was introduced to speed up the ingestion of large single files. It allows multiple Backends (BEs) to participate in the parsing and loading of a single data stream concurrently. This type typically appears in your load history if: 1. You explicitly set the header: 
-H "parallel: true"
in your 
curl
or application request. 2. Using Transactional/Multi-table Load: In some versions or configurations of the Stream Load Transaction interface (which you are using, given the 
/api/transaction/load
endpoint and 
cdc-
label), StarRocks may categorize the sub-tasks or the transaction type this way to optimize performance. Is it a problem? No, it is not an error. It simply indicates the "Execution Mode" StarRocks is using for that specific load. Why did it fail before but show up now? The reason you didn't see it before is likely because the "No rows were imported" error happened so early (during parsing) that the FE didn't register a "Completed" or "Visible" load job yet. Now that you are seeing it: * Check the State: If the state is 
CANCELLED
or 
FAILED
, look at the 
ErrorMsg
or 
ErrorURL
in that same row to find the parsing error I mentioned earlier (likely the invalid JSON format). * Check the Label: Ensure the label matches the one from your failing logs (
cdc-1784124467425-f1a23ea3
). Summary: The type 
PARALLEL_STREAM_LOAD
is a valid and expected type for high-performance stream loading in modern StarRocks versions. Your focus should remain on the JSON format of your data and the ErrorMsg/ErrorURL within that load entry. References • loading/StreamLoad.md • sql-reference/sql-statements/loading_unloading/STREAM_LOAD.md • loading/Stream_Load_transaction_interface.md
c
@Rocky i have seen this error: Failed to access err: Internal error: URL rejected: Malformed input to a URL function be/src/exec/schema_scanner/schema_load_tracking_logs_scanner.cpp:141 client->execute(&tracking_msg) in the information_schema.load_tracking_logs
r
The error 
Malformed input to a URL function
inside 
schema_load_tracking_logs_scanner.cpp
indicates that the internal system view (
load_tracking_logs
) is failing to parse the tracking URL associated with your load task. This can happen if the internal address of the Backend (BE) is misconfigured or if there is a bug in how that specific version of StarRocks handles the error path for 
PARALLEL_STREAM_LOAD
. Since the system view is broken, you should bypass it and use these manual debugging methods: 1. Get the Raw Error URL Run this query to find the direct link to the error logs:
Copy code
sql
SELECT LABEL, REJECTED_RECORD_PATH, ERROR_MSG 
FROM information_schema.loads 
WHERE LABEL = 'cdc-1784124467425-f1a23ea3';
* If 
REJECTED_RECORD_PATH
is present: Copy the URL and use 
curl
or a browser to view it. _ _Note:* If the URL uses an internal IP you can't reach, replace the IP with the public/reachable IP of your BE node. * If it is NULL: This confirms that the data didn't even reach the "filtering" stage—it failed at the parsing stage. 2. Check BE Logs (Most Reliable) When 
No rows were imported
occurs and the system views fail, the Backend logs will tell you exactly why. 1. Identify the BE node processing the request (from your previous log: 
starrocks-be
). 2. Search the 
<http://be.INFO|be.INFO>
log for the label:
Copy code
bash
    grep "cdc-1784124467425-f1a23ea3" storage/log/be.INFO
3. Look for lines containing 
[PARSE_ERROR]
or 
failed to parse json
. 3. Likely Root Cause: JSON Syntax Since you are seeing 
PARALLEL_STREAM_LOAD
and 
No rows were imported
, the most common cause is a JSON format mismatch. StarRocks is very strict: * Double Quotes: All keys and string values must use double quotes (
"key": "value"
). Single quotes (
'
) or unquoted keys will cause the entire load to return 0 rows. * Hidden Characters: Ensure there are no trailing commas or non-standard whitespace in your JSON payload. Summary of what to do: 1. Stop using 
information_schema.load_tracking_logs
for this specific task as it's hitting a URL parsing bug. 2. Check the BE log to see the raw parsing error. 3. Verify your JSON payload matches this format exactly:
Copy code
json
    {"internal_id": "1016123958008284866", "internal_store_id": "3853049300414731940"}
References • sql-reference/information_schema/load_tracking_logs.md • loading/loading_introduction/troubleshooting_loading.md • sql-reference/information_schema/loads.md References • sql-reference/information_schema/load_tracking_logs.md • loading/loading_introduction/troubleshooting_loading.md • administration/management/BE_configuration.md • sql-reference/information_schema/loads.md
2 Views
Open in Slack
PreviousNext
Powered by