Commit cbac64f
committed
fix: use a monotonic clock for the cache polling timeout
`pollLocalCache` computed its deadline with `LocalTime`:
var startTime = LocalTime.now();
final var timeoutTime = startTime.plus(timeoutMillis, ChronoUnit.MILLIS);
while (timeoutTime.isAfter(LocalTime.now())) {
`LocalTime` is a time of day and wraps at midnight, so for any call made
within `timeoutMillis` of 00:00 the computed deadline is *earlier* than
the current time. The loop body never runs and the method throws
`OperatorException("Timeout of resource polling from cache for resource")`
immediately, failing the update it was retrying even though the resource
would have appeared in cache. With the default 10s timeout that is a
10-second window each day.
`LocalTime.now()` is also wall-clock based, so an NTP step or a DST change
can shorten or extend the timeout.
Switches to `System.nanoTime()`, which is monotonic and has no wrap-around
concern, using overflow-safe subtraction for the comparison.
No test is added: reproducing this requires controlling the clock, and the
class is already deprecated for removal.1 parent 3e85d04 commit cbac64f
1 file changed
Lines changed: 3 additions & 5 deletions
File tree
- operator-framework-core/src/main/java/io/javaoperatorsdk/operator/api/reconciler
Lines changed: 3 additions & 5 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
16 | 16 | | |
17 | 17 | | |
18 | 18 | | |
19 | | - | |
20 | | - | |
| 19 | + | |
21 | 20 | | |
22 | 21 | | |
23 | 22 | | |
| |||
232 | 231 | | |
233 | 232 | | |
234 | 233 | | |
235 | | - | |
236 | | - | |
237 | | - | |
| 234 | + | |
| 235 | + | |
238 | 236 | | |
239 | 237 | | |
240 | 238 | | |
| |||
0 commit comments