feat: improve task polling with exponential backoff #408
Conversation
Implements an improved task polling mechanism with configurable exponential backoff to reduce the number of API calls for long-running tasks. This helps to minimize resource consumption on the Connect server while still providing responsive feedback. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
☂️ Python Coverage
Overall Coverage
New FilesNo new covered files... Modified Files
|
tdstein
requested review from
jonkeane,
nealrichardson,
cgraham-rs and
a team
and removed request for
jonkeane and
nealrichardson
There was a problem hiding this comment.
Pull Request Overview
This pull request improves task polling by introducing an exponential backoff mechanism with configurable parameters to reduce API call frequency for long-running tasks. Key changes include:
- Adding a new wait_for method signature that accepts initial_wait, max_wait, and backoff parameters
- Extending task polling tests to verify both exponential backoff and non-backoff configurations
- Updating documentation within the wait_for method to clearly explain the new behavior
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| tests/posit/connect/test_tasks.py | Added tests for exponential backoff and no-backoff scenarios |
| src/posit/connect/tasks.py | Updated wait_for to support configurable backoff parameters and improved docstring |
| while not self.is_finished: | ||
| self.update() | ||
|
|
||
| # Wait client-side | ||
| time.sleep(wait_time) |
There was a problem hiding this comment.
I was trying to suggest using the wait=N query argument to implement long-polling and not do any sleeping on the client.
There was a problem hiding this comment.
Given that the sdk's http client is not async, I am curious what relying on long polling would gain here. Could be mistaken but whether you have a long standing connection or sleep, both are blocking until the response is returned right? If that is accurate then having the blocking driven by the client may still give this a slight edge.
There was a problem hiding this comment.
when you call /tasks/DECAFBAD?wait=10, the API call will wait up to ten seconds or until the task is complete before returning. read that call as "accumulate data for up to 10 seconds before returning the result".
the call returns as soon as the task is complete.
when the client is sleeping, it has to wait the entire duration before it can make an API call to fetch additional data. if the task completes after 1s, you still need to wait the remaining 9s.
There was a problem hiding this comment.
the rsconnect R package uses wait=1 to provide fairly fast feedback while not issuing an excessive number of HTTP requests.
There was a problem hiding this comment.
the call returns as soon as the task is complete.
that makes sense then! I didnt know that it would return early.
There was a problem hiding this comment.
Ah, I completely spaced on the API functionality for sleeps. I'll modify the implementation to use it.
There was a problem hiding this comment.
Much better :) #409
Implements an improved task polling mechanism with configurable exponential backoff to reduce the number of API calls for long-running tasks. This helps to minimize resource consumption on the Connect server while still providing responsive feedback.
🤖 Generated with Claude Code