Azure / Azure/azure-openai-benchmark

RETRY_AFTER_MS_HEADER not getting properly "honored"

Open
#33 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
154
Forks
76
PR merge metrics
No merged PRs in 30d

Description

Considering following code,

image

In the context of this code, if the RETRY_AFTER_MS_HEADER is found in the response headers, the function will sleep for that much time but then the function will resume from the point where asyncio.sleep was called, not from the start of the function or the start of the while loop.

Thus, in cases when the RETRY_AFTER_MS_HEADER duration would be greater than MAX_RETRY_SECONDS, which is very much possible, considering how much less the value of MAX_RETRY_SECONDS (5s) currently is, the condition of the while loop will be false after waking from the thread sleep as the while loop is considering the stale time value capture from the 1st incident of throttling, hence the while loop will not continue, effectively meaning the request will not be retried.

_Suggestions:_
1. The time check logic in while loop should not be based on the stale value and should update considering the time difference of thread sleep from RETRY_AFTER_MS_HEADER sleep condition.
2. Value for MAX_RETRY_SECONDS should not be hardcoded and be made configurable and decided by user. See [#36 ](https://github.com/Azure/azure-openai-benchmark/issues/36)
3. Documenting about MAX_RETRY_SECONDS and letting the users know how it works. See [#37](https://github.com/Azure/azure-openai-benchmark/issues/37)

Contributor guide

No contributing guide indexed for this repository

Research direction

Start with the retry loop shown in the issue and inspect how RETRY_AFTER_MS_HEADER, asyncio.sleep, and MAX_RETRY_SECONDS interact. Reproduce a response whose retry-after duration exceeds five seconds, then verify that the request is retried and that the elapsed-time check reflects the sleep before considering the retry window exhausted.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.