SEPURI-SAI-KRISHNA commented on PR #18544:
URL:
https://github.com/apache/dolphinscheduler/pull/18544#issuecomment-5261336547
@ruanwenjun
> Do all instances of the same task have end times within the same second?
No, and they don't need to. Two attempts of **one** task code ending in the
same second is enough to
break the whole dependency check, because `DependentExecute` collects every
task of the workflow into
one map:
```java
.collect(Collectors.toMap(TaskInstance::getTaskCode,
TaskInstance::getState));
```
A single duplicated key throws, so one tied pair among a hundred well-spaced
tasks fails the
dependent task for the entire upstream workflow.
When two attempts do tie:
- `failRetryInterval` is allowed to be `0` (`use-failed.ts`, `props: { min:
0 }`), so an immediate
retry is a supported configuration, and a task that fails fast (bad
command, connection refused,
a failure raised before the task really starts) can fail and be retried
inside the same second.
- On MySQL the tie is much easier than "same millisecond", because
`t_ds_task_instance.end_time` is a `datetime` with no fractional seconds:
```sql
`end_time` datetime DEFAULT NULL COMMENT 'task end time',
```
Any sub-second difference between the two attempts is erased on write, so
they only have to land
in the same wall-clock second.
To be straight about the exposure: on PostgreSQL `end_time` is a `timestamp`
with microsecond
precision, so a tie there is far less likely. This is mostly a MySQL
problem, and it needs a fast
retry. It is narrow, but it is reachable with a stock configuration, and the
failure mode is a hard
exception rather than a wrong result.
--
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]
