wank125 opened a new pull request, #18678:
URL: https://github.com/apache/dolphinscheduler/pull/18678
## Was this PR generated or assisted by AI?
YES — the fix, the regression test and this description were drafted with AI
assistance (Claude-based coding agent). The bug was discovered while operating
a production DolphinScheduler 3.2.2 deployment; the change was reviewed locally
by the submitter (the service module compiles and passes spotless locally; the
master module could not be built in the submitter's network environment due to
an unrelated dependency range resolution issue, so CI validation is relied upon
for it).
## Purpose of the pull request
Fixes #18677
Task definitions created via the **export → import** round trip can carry
`taskExecuteType = null` (exported JSON has no such field, import does not
default it, and the DB column has no default value). When such a task finishes:
```
WorkflowInstanceUtils#logTaskInstanceInDetail -> NPE
(getTaskExecuteType().getDesc() on null)
-> state event retried 4x, all fail -> dropped
-> task instance stuck in RUNNING forever, workflow instance never completes,
master re-dispatches the shell repeatedly
```
A pure logging helper thus has the power to crash the task finish chain.
Verified on a production 3.2.2 deployment: 48 imported task definitions with
`task_execute_type NULL` reproduced the stuck state deterministically; fixing
the data restored normal completion immediately.
## Brief change log
- `WorkflowInstanceUtils#logTaskInstanceInDetail`: render null
`taskExecuteType` as `N/A` instead of throwing — a logging helper must not be
able to take down the task finish event chain
- `ProcessServiceImpl#saveTaskDefine`: default a missing `taskExecuteType`
to `BATCH`, so task definitions saved from workflow import (and any other
caller) never persist null
## Verify this pull request
This change added tests and can be verified as follows:
- Added `testLogTaskInstanceInDetailWithNullTaskExecuteType` to
`WorkflowInstanceUtilsTest`: invoking the log helper with a null
`taskExecuteType` no longer throws and renders `N/A`
- End-to-end verification was performed on a 3.2.2 deployment as described
in the issue (deterministic reproduction before, immediate recovery after the
data fix)
--
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]
