[Bug] [Process] sheduler exist critical value problem when process complement data

[RickyHu]

Search before asking

• [X] I had searched in the issues and found no similar issues.

What happened

  工作流的调度时间是每日0点整，现在操作运行补数，设置时间为某一日的 00:00:00~23:59:59，运行之后理论上只会产生这一天0点一个实例，但实际结果是产生了这一天以及第二天的0点两个实例：

后面我debug源码，发现在获取补数范围内的所有调度时间时的一段代码：org.apache.dolphinscheduler.service.cron.CronUtils.getSelfFireDateList 为支持左闭右闭时间区间，将开始时间减1s，结束时间加1s，变成了 昨日23:59:59~次日00:00:00，在后面的搜寻两个调度时间点。

What you expected to happen

希望快点修复这个调度临界值问题

How to reproduce

这个问题在补数的时候很容易复现，只要补数范围的结束时间正好比调度时间点晚1s，最终产生的部署实例都会比预期多出一个。

Anything else

No response

Version

3.2.x

Are you willing to submit PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[github-actions[bot]]

Search before asking

• [X] I had searched in the issues and found no similar issues.

What happened

  The scheduling time of the workflow is 0:00 every day. Now the operation is run complementally. The setting time is 00:00:00~23:59:59 on a certain day. After running, theoretically only one instance will be generated at 0:00 on this day. , but the actual result is to generate two instances at 0 o'clock on this day and the next day:

Later, I debugged the source code and found a piece of code for obtaining all scheduling times within the complement range: org.apache.dolphinscheduler.service.cron.CronUtils.getSelfFireDateList In order to support the left-closed and right-closed time interval, the start time is reduced by 1s and the end time is added by 1s, which becomes 23:59:59 yesterday to 00:00:00 the next day. Two scheduling time points are searched for later.

What you expected to happen

I hope this scheduling threshold issue will be fixed soon.

How to reproduce

This problem is easy to reproduce when complementing the number. As long as the end time of the complement range is exactly 1 second later than the scheduling time point, the final deployment instance will be one more than expected.

Anything else

No response

Version

3.2.x

Are you willing to submit PR?

• [ ] Yes I am willing to submit a PR!

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[wangxj3]

ChronoZonedDateTime.isAfter algorithm, the calculation accuracy is nanoseconds, which is theoretically equal here, but the time calculation method may be different, resulting in the time + 1 second set by the page, which is greater than the next start time. Here the end time + 1 second is the start that wants to include the end time. I understand that just remove the logic of the end time + 1. But why this nanosecond doesn't wait needs to be checked in detail

ChronoZonedDateTime.isAfter 算法，计算的精度是纳秒，理论上这里也是相等的，但是时间计算方式可能会不同，导致页面设置的时间+1秒，就大于了下一次启动时间。这里结束时间+1秒是想要包含结束时间的启动。我理解把结束时间+1的逻辑去掉就可以了。但是这个纳秒为什么不等还需要再具体查一下