fix(scheduler): clamp backoff exponent to prevent duration overflow

[devteamaegis]

What's broken

calculateBackoffDelay computes retry backoff as time.Duration(math.Pow(2, retryCount)) * baseDelay and clamps it to a 5s maxDelay. For large retryCount, the time.Duration (int64 ns) overflows before the clamp, wrapping to 0 then negative — so the clamp never fires and failing requests get zero/negative backoff instead of the intended 5s cap. retryCount is reachable up to maxScheduleRetryCount = 120:

retryCount=3   -> 5s    (correct, clamped)
retryCount=62  -> 0s    (bug: no backoff)
retryCount=63  -> -1s   (bug: negative)
retryCount=119 -> -1s   (bug)

A negative/zero duration makes the backlog reschedule immediately, turning the backoff cap into a retry storm — the opposite of its purpose.

Why it happens

math.Pow(2, retryCount) converted to time.Duration and multiplied by 1s overflows int64 around retryCount >= 62; the overflowed value is <= maxDelay, so if delay > maxDelay is skipped.

Fix

Clamp the exponent before the power: if retryCount exceeds a safe bound, return maxDelay directly.

Test

TestCalculateBackoffDelay asserts retryCount 62/63/119 return the 5s cap (not 0/negative); fails before, passes after. Full scheduler package still green.

---

Summary by cubic

Clamps the retry backoff exponent in pkg/scheduler to prevent time.Duration overflow that caused zero/negative delays and retry storms. High retry counts now correctly return the 5s cap.

• Bug Fixes
  • Clamp before power: if retryCount > 32, return maxDelay (5s).
  • Added TestCalculateBackoffDelay to cover large counts (62, 63, 119) and assert non-negative, capped delays.

^{Written for commit 8f87ad0. Summary will update on new commits.}