This message text isn’t a log_print() line from your script (it lacks the [HH:MM:SS] prefix format you use everywhere else) — it looks like it’s coming from the underlying Tradehull SDK or the execution platform itself, logged directly via its own print/stderr rather than through your log_queue.
If it’s an unhandled exception at the SDK level that bypassed your try/except wrapping (e.g., raised on a thread your call_with_timeout doesn’t wrap, or during the Tradehull() login call itself if this happened during a reconnect), it could have killed the process rather than triggering reconnect_client().
Given there are no further log lines after it, and no [RECONNECT] attempt logged, it’s worth checking whether the process actually died here, leaving the BEARISH position (10 open legs, entry ~11:34:52) unmonitored — no more mark-to-market, no risk guard, no EOD squareoff.
That last point is the important operational risk: if this timeout happened outside your call_with_timeout/retry_call protection (i.e., not on a wrapped call), the process could exit with an open position and nothing watching it. Want me to help trace which call in the code this timeout most likely came from, based on where the log stream cuts off?
Please help me resolve this issue