Description
get_next_action() is asynchronous, but its gpt-4 branch invokes the synchronous call_gpt_4o() function directly.
If the model request takes time to complete, the synchronous call occupies the event-loop thread for the duration of the request, preventing other scheduled asynchronous work from progressing.
I reproduced this behavior with a controlled local replacement for call_gpt_4o() that blocks for 0.25 seconds. No model API or network endpoint is contacted.
Observed behavior:
Selected model: gpt-4
Simulated synchronous model-call delay: 0.25 s
get_next_action() elapsed time: approximately 0.252 s
Event-loop timer delay: approximately 0.232 s
External network contacted: No
This means latency in the synchronous model request can directly stall unrelated coroutines and timers running on the same event loop.
Affected Version
Confirmed on:
self-operating-computer==1.5.8
operate/models/apis.py:34-39
get_next_action()
PoC runtime:
Python 3.10.12
Other versions have not been tested.
Reproduction
The attached PoC loads the released get_next_action() implementation and executes its gpt-4 branch.
call_gpt_4o() is replaced with a local synchronous function that sleeps for 0.25 seconds before returning a fixed result. At the same time, an event-loop timer is scheduled to fire after 0.02 seconds.
Observed result:
blocking model-call delay: 0.25 s
asynchronous function elapsed time: approximately 0.252 s
event-loop timer delay: approximately 0.232 s
synchronous model-call event-loop blocking reproduced: yes
No actual model request or external network request is made during reproduction.
Attachment
run.py
Description
get_next_action() is asynchronous, but its gpt-4 branch invokes the synchronous call_gpt_4o() function directly.
If the model request takes time to complete, the synchronous call occupies the event-loop thread for the duration of the request, preventing other scheduled asynchronous work from progressing.
I reproduced this behavior with a controlled local replacement for call_gpt_4o() that blocks for 0.25 seconds. No model API or network endpoint is contacted.
Observed behavior:
Selected model: gpt-4
Simulated synchronous model-call delay: 0.25 s
get_next_action() elapsed time: approximately 0.252 s
Event-loop timer delay: approximately 0.232 s
External network contacted: No
This means latency in the synchronous model request can directly stall unrelated coroutines and timers running on the same event loop.
Affected Version
Confirmed on:
self-operating-computer==1.5.8
operate/models/apis.py:34-39
get_next_action()
PoC runtime:
Python 3.10.12
Other versions have not been tested.
Reproduction
The attached PoC loads the released get_next_action() implementation and executes its gpt-4 branch.
call_gpt_4o() is replaced with a local synchronous function that sleeps for 0.25 seconds before returning a fixed result. At the same time, an event-loop timer is scheduled to fire after 0.02 seconds.
Observed result:
blocking model-call delay: 0.25 s
asynchronous function elapsed time: approximately 0.252 s
event-loop timer delay: approximately 0.232 s
synchronous model-call event-loop blocking reproduced: yes
No actual model request or external network request is made during reproduction.
Attachment
run.py