RFR: 1659: Fix polling and retries in testinfo bot [v2]
Erik Joelsson
erikj at openjdk.org
Tue Nov 15 22:25:48 UTC 2022
On Tue, 8 Nov 2022 10:29:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:
>> bots/testinfo/src/main/java/org/openjdk/skara/bots/testinfo/TestInfoBot.java line 63:
>>
>>> 61: .filter(pr -> pr.sourceRepository().isPresent())
>>> 62: .map(pr -> (WorkItem) new TestInfoBotWorkItem(pr,
>>> 63: delay -> poller.retryPullRequest(pr, now.plus(delay))))
>>
>> Maybe I'm getting lost here, but this feels wrong to me. The `now` is computed as the now of the call to `getPeriodicItems()`, but it is used in the lambda for the `retry` operation of `TestInfoBotWorkItem`. But that retry should happen `delay` time after it is evaluated, right?
>>
>> It might not have much practical impact, but it just looks odd to me, like mixing different time streams.
>
> To expand a bit: the `now.plus(delay)` will be evaluated in the `run` method of the work item, but then the result will be offset not from the time of `run` but from the time of the call to this method. What would happen if it, for some reason, would take more than 2 minutes between these two events, and we'd get a time in the past. Will it be retried immediately, or will it cause trouble with the poller?
>
> And also it feel conceptually wrong; the retry time feels like it should be specified from when the decision is made for the next check.
You are right, that is odd, it really should be X minutes after it was evaluated, not after the `getPeriodicItems` call. When bots are busy, the time difference can easily be much longer than 2 minutes, and in that case, effectively ignoring the delay is not helping in reducing the load.
The poller should handle past time fine though, it will basically be equivalent to a retry without a time component.
-------------
PR: https://git.openjdk.org/skara/pull/1411
More information about the skara-dev
mailing list