Replace Static Polling Loop With p-retry
Summary
The current static rendition polling uses a hard while loop with a fixed interval. In serverless environments this can behave unpredictably if the function hits its timeout, and we may lose error visibility. We should refactor this polling to use p-retry, which is already installed.
Problem
- Hard loops can continue retrying until the serverless function is killed, with no final error logged.
- Abort signals are not currently respected, which can lead to unnecessary work and extra cost.
- The total polling window is not clearly bounded relative to serverless function timeouts.
Proposed Direction
- Replace the manual polling loop with
p-retry for static rendition polling.
- Wire in an
AbortSignal so callers can stop retries when appropriate.
- Introduce a
maxTimeout or equivalent that:
- Stays under typical serverless function timeouts, and
- Is configurable for users running on traditional servers.
- Revisit the current three minute limit and choose a more conservative default for serverless use.
Tasks
- Implement
p-retry based polling for static rendition checks.
- Add configuration options for retry interval, max attempts, and max total timeout.
- Ensure abort handling is tested and documented.
Replace Static Polling Loop With
p-retrySummary
The current static rendition polling uses a hard
whileloop with a fixed interval. In serverless environments this can behave unpredictably if the function hits its timeout, and we may lose error visibility. We should refactor this polling to usep-retry, which is already installed.Problem
Proposed Direction
p-retryfor static rendition polling.AbortSignalso callers can stop retries when appropriate.maxTimeoutor equivalent that:Tasks
p-retrybased polling for static rendition checks.