[lihanyu1715446406-afk]

Was this PR generated or assisted by AI?

YES. The root-cause analysis, the regression tests and this description were drafted with AI assistance (Claude Code). The change was reviewed and verified locally by the submitter, including a before/after run of the new tests.

Purpose of the pull request

Fixes #18697. DinkyTask.submitApplicationV0() and submitApplicationV1() restore the interrupt flag in a catch (Exception) block even though the try block only performs HTTP calls and JSON parsing. When a Dinky submit fails, the flag is set on the worker's TaskExecutorWorker thread. The next Condition.await() then throws InterruptedException, the worker breaks out of its loop and its slot is never submitted again. Repeating this eventually exhausts the fixed pool (All ExclusiveThreadTaskExecutorWorker are busy).

Brief change log

• Remove the two spurious Thread.currentThread().interrupt() calls from the submit-failure paths. trackApplicationStatusV0/V1 still restore the flag in their real catch (InterruptedException) blocks.
• Add DinkyTaskTest with two regression tests (dinky 0.x and 1.x) that fail the submit call via a local HTTP server and assert that the task throws TaskException while the worker thread's interrupt flag stays clear.

Verify this pull request

This change added tests and can be verified as follows:

• ./mvnw -pl dolphinscheduler-task-plugin/dolphinscheduler-task-dinky -Dtest=DinkyTaskTest test
• Before the fix: both tests fail with a failed submit must not leave the worker thread interrupted ==> expected: <false> but was: <true>.
• After the fix: Tests run: 2, Failures: 0, Errors: 0, Skipped: 0.

This PR intentionally stays scoped to the interrupt leak. The secondary defensive liveness check in TaskExecutorWorkers#selectIdleWorker() is not changed here.

[boring-cyborg]

Thanks for opening this pull request! Please check out our contributing guidelines. (https://github.com/apache/dolphinscheduler/blob/dev/docs/docs/en/contribute/join/pull-request.md)

[SbloodyS]

LGTM