Closed LeonKalt closed 2 weeks ago
We temporarily could fix the issue by adding await aoai_response.aread()
to the status check.
if aoai_response.status_code != 200:
# print infos to console
await aoai_response.aread()
print(
(
f"Unexpected HTTP Code {aoai_response.status_code} while using target '{aoai_target['name']}'. "
f"Text: {aoai_response.text} "
f"Path: {routing_slip['path']} "
f"Url: {aoai_target['url']}"
)
)
No we get Unexpected HTTP Code 408 while using target ...
Errors that are no handled by the following
# got 429 or 500
if aoai_response.status_code in [429, 500]:
# block endpoint for some time, either according to the time given by AOAI or, if not
# available, for 10 seconds
waiting_time_ms_until_next_request = (
int(aoai_response.headers["retry-after-ms"]) if "retry-after-ms" in aoai_response.headers else 10_000
)
aoai_target["next_request_not_before_timestamp_ms"] = (
get_current_timestamp_in_ms() + waiting_time_ms_until_next_request
)
# try next target
continue
Shouldn't this include handling of timeouts as well?
@LeonKalt I have fixed the .aread() issue and checked into main. I will create a new release later today. Thanks for reaching out and bringing this up!
The 408 timeout occurs when the client does not send the request fast enough to the server. If I add 408 to the list, we would simply hide an issue which could/should potentially be fixed. Do you have an idea why a 408 is encountered in your scenario? Could it be related to where you host PowerProxy and/or how the network connection is under pressure? What kind of prompts are you sending? Is larger prompts? Just trying to better understand the context before adding 408 to the list above. Thanks!
I have seen you have opened another timeout-related issue, rendering this as duplicate, hence closing.
@LeonKalt I have fixed the .aread() issue and checked into main. I will create a new release later today. Thanks for reaching out and bringing this up!
The 408 timeout occurs when the client does not send the request fast enough to the server. If I add 408 to the list, we would simply hide an issue which could/should potentially be fixed. Do you have an idea why a 408 is encountered in your scenario? Could it be related to where you host PowerProxy and/or how the network connection is under pressure? What kind of prompts are you sending? Is larger prompts? Just trying to better understand the context before adding 408 to the list above. Thanks!
Our managed PTU had some issues so we ran into a scenario where customers where effected instead of falling back on our paygo deployment and although I understand the issue of hiding errors, I think full filling the request with an answer is preferable to just returning an error to the application.
@LeonKalt Ok I see. I have added the 408/Request Timeout code to the list of codes that will trigger trying the next AOAI target instead of just forwarding the 408 back. New release is out.
Hey we are currently experiencing the follow error on v0.10.3: