When starting connecting to Talo API, it often randomly returns 13 timeout signal on the health api

[lmsonic]

This happens everytime when auto_connect_socket=true, but also kind of randomly when we start a connection manually with Talo.players.identify("username", talo_identity). This started to happen when we upgraded the project to Godot 4.6.1, we were previously 4.4.1, with Talo plugin 0.37, and now we are a 0.43. I tried to regress to the version of the plugin at 0.37, but it doesn't fix it. Some times it does stay fixed for a while, but today for example, it was connecting to Talo while in the editor, i tried making a build, it didn't connect there and i tried to run in the editor and it stopped connecting there too.
This is the kind of request and responses i get

<-- GET https://api.trytalo.com/public/health 
--> GET https://api.trytalo.com/public/health [0] { &"message": "Request failed: result 13, details: https://docs.godotengine.org/en/stable/classes/class_httprequest.html#enum-httprequest-result" }

I'm using Linux Mint, if that matters.

[lmsonic]

I see that you pushed a new version, i´ll check if it fixes anything

[lmsonic]

I see that you pushed a new version, i´ll check if it fixes anything

Nope, doesn't fix it unfortunately :c

[tudddorrr]

Hey @lmsonic - I think there's potentially an issue happening with newer versions of Godot where the timeout doesn't work as expected.

This is the timeout:
http_request.timeout = 5

You can either bump it up (try 10, 15, etc) or simply remove it. I'm looking into a fix for this.

[lmsonic]

Thank you! Bumping it / removing it fixes it!

[ohin]

We hit the same issue on Android (Godot 4.6.1, Talo 0.42) and traced it through the Godot source code. This is what Claude reports as an explanation and fix we used in our case:

Root cause

main_timer_sync.init() is called before scene loading (main.cpp:4020). The first main loop iteration computes _process_step as elapsed time since init() (main_timer_sync.cpp:508-514) — this includes the entire scene loading time.

In SceneTree::process() (scene_tree.cpp:709-715):

emit_signal("process_frame")    // 709
MessageQueue::flush()            // 711 — deferred calls from _ready() run here
_process(false)                  // 715 — Timer ticks here

Any HTTPRequest created before line 715 of the first iteration — whether directly in _ready() or from deferred calls flushed at line 711 — gets its Timer ticked at line 715 with _process_step = scene loading time. If that exceeds HTTPRequest.timeout (15s), the Timer fires immediately → RESULT_TIMEOUT.

HTTPClient is unaffected because it has no Timer — it just polls the connection each frame.

Workaround (no plugin changes)

await get_tree().process_frame
await get_tree().process_frame
# Now _process_step is normal — safe to make requests

Two awaits are needed because process_frame fires before _process() in the same iteration (line 709 vs 715).

[tudddorrr]

@ohin were you able to reproduce this consistently somehow?

[ohin]

Yes, absolutely. If the duration of the first frame is longer then the timeout, and you make a request in the first frame (maybe also in the second frame), the request timeouts immediately.

Or in other words, the duration of the first frame gets immediately subtracted from the timeout period right from the start of the request.

One of the nice solutions to this is to use HTTPClient (it does not have the timeout mechanic) and is also more efficient as you keep reusing it for additional requests.