github-actions[bot] commented on code in PR #65553:
URL: https://github.com/apache/doris/pull/65553#discussion_r3575489749
##########
fe/fe-core/src/main/java/org/apache/doris/load/routineload/RoutineLoadJob.java:
##########
@@ -1408,8 +1419,8 @@ private void
executeTaskOnTxnStatusChanged(RoutineLoadTaskInfo routineLoadTaskIn
routineLoadTaskInfo.handleTaskByTxnCommitAttachment(rlTaskTxnCommitAttachment);
}
- if (rlTaskTxnCommitAttachment != null &&
!Strings.isNullOrEmpty(rlTaskTxnCommitAttachment.getErrorLogUrl())) {
- errorLogUrls.add(rlTaskTxnCommitAttachment.getErrorLogUrl());
+ if (rlTaskTxnCommitAttachment != null) {
+ updateJobInfoFromAttachment(rlTaskTxnCommitAttachment);
Review Comment:
This still misses the cloud rollback path. BE now puts `firstErrorMsg` into
the rollback attachment, but `CloudGlobalTransactionMgr.abortTransaction(...,
txnCommitAttachment, ...)` calls `abortTransactionImpl(dbId, transactionId,
reason, null)`, so the `AbortTxnRequest` sent to meta-service has no commit
attachment. The abort response then reconstructs a `TransactionState` without
`txnCommitAttachment`, and this new `updateJobInfoFromAttachment()` block is
skipped. In cloud mode an all-filtered routine-load task therefore still loses
the first error message on the live abort path. Please pass the rollback
attachment through the cloud abort request/response path or reattach it before
`afterAborted()`, and cover that cloud abort case.
##########
cloud/src/meta-service/meta_service_txn.cpp:
##########
@@ -578,6 +578,11 @@ void put_routine_load_progress(MetaServiceCode& code,
std::string& msg,
new_progress_info.mutable_partition_to_offset()->insert(elem);
}
}
+ if (commit_attachment.has_first_error_msg()) {
+
new_progress_info.set_first_error_msg(commit_attachment.first_error_msg());
Review Comment:
This carry-forward needs to be applied in the other cloud routine-load
progress writer too. When `ALTER ROUTINE LOAD` resets Kafka offsets,
`KafkaRoutineLoadJob.modifyPropertiesInternal()` sends
`ResetRLProgressRequest.partition_to_offset`, and `reset_rl_progress()` builds
a fresh `RoutineLoadProgressPB` from the requested offsets plus previous
offsets. That branch preserves old offsets for untouched partitions, but it
does not copy `prev_progress_info.first_error_msg()`, so the next meta-service
refresh/restart loses the diagnostic even though normal commits now preserve it
here. Please carry `first_error_msg` through the reset writer as well, or
explicitly clear the FE display field at the same semantic boundary and test
that behavior.
##########
be/src/load/stream_load/stream_load_executor.cpp:
##########
@@ -99,6 +99,7 @@ Status StreamLoadExecutor::execute_plan_fragment(
ctx->loaded_bytes = state->num_bytes_load_total();
int64_t num_selected_rows = ctx->number_total_rows -
ctx->number_unselected_rows;
ctx->error_url =
to_load_error_http_path(state->get_error_log_file_path());
+ ctx->first_error_msg = state->get_first_error_msg();
if (status->ok() && !ctx->group_commit && num_selected_rows > 0 &&
Review Comment:
This assignment now also affects successful ordinary stream loads that have
filtered rows. `RuntimeState::append_error_msg_to_file()` stores the full
source line in `_first_error_msg`, and `StreamLoadContext::to_json()` writes it
directly into `FirstErrorMsg`; for successful stream loads that JSON is also
saved through `prepare_stream_load_record()` into the BE stream-load recorder
and later shown by FE stream-load history. The FE-side cap in
`RLTaskTxnCommitAttachment` only protects routine-load transaction attachments,
so a large bad input row can still produce a very large HTTP response/history
record. Please cap or otherwise bound the value before storing it in
`ctx->first_error_msg` or before serializing it into stream-load output.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
