Repository navigation
Conversation
luoluoyuyu
left a comment
There was a problem hiding this comment.
Review summary
Keeps only the latest pipe exception for display, avoids clearing it automatically, and adds suggested actions. trackException clears then adds a single entry; coordinator meta sync clears exceptions on the agent to avoid stale overwrites.
Please fix failing CI before merge. See inline notes.
| // Here we still keep the map form to allow compatibility with legacy versions | ||
| exceptionMessages.clear(); | ||
| exceptionMessages.add(exceptionMessage); | ||
| lastException.clear(); |
There was a problem hiding this comment.
clear then add enforces a single last exception. If SHOW PIPES now exposes last_exception as a structured column, consider whether getExceptionMessage() (Set toString) should be updated or deprecated for user-facing output.
There was a problem hiding this comment.
Kept the existing exception serialization and restored the user-facing column names to ExceptionMessage / exception_message for compatibility. TPipeInfo.exceptionMessage and existing SHOW PIPES / information_schema clients therefore keep the same contract; this PR only adds the separate SuggestedAction column.
| .getRuntimeMeta() | ||
| .getConsensusGroupId2TaskMetaMap() | ||
| .values() | ||
| .forEach(PipeTaskMeta::clearExceptionMessages); |
There was a problem hiding this comment.
Clearing exceptions when applying meta from the coordinator prevents old CN-reported errors from overwriting the true last error on the DataNode after restart. Matches the do-not-auto-clear behavior for operators.
There was a problem hiding this comment.
Agreed. This behavior is intentionally preserved: coordinator-provided exceptions are cleared before applying the metadata so they cannot overwrite the DataNode's locally tracked latest exception.
|
Addressed the review and current deterministic CI failures in 0811b05:
The related pipe/meta unit tests pass. A focused local IT build compiled all relevant modules, but the locally injected com.timecho.ao plugin prevents JDBC startup by calling the removed IoTDBConfig.isEnableWhiteList() method, so the IT itself could not execute in this environment. The latest GitHub dual-table-manual-basic run is green. |
…pr-16233 # Conflicts: # integration-test/src/test/java/org/apache/iotdb/relational/it/schema/IoTDBDatabaseIT.java # iotdb-core/datanode/src/main/java/org/apache/iotdb/db/queryengine/plan/execution/config/sys/pipe/ShowPipeTask.java # iotdb-core/datanode/src/test/java/org/apache/iotdb/db/queryengine/plan/execution/config/sys/pipe/ShowPipeTaskTest.java
Description
As the title said.
Test
This PR has:
for an unfamiliar reader.
for code coverage.
Key changed/added classes (or packages if there are too many classes) in this PR