Rodribm10 978ccbbdfb fix(captain): wrap runner.run in Timeout to guard HTTP hangs ... Observed incident 2026-04-19 14:34: ResponseBuilderJob sat 156s 'Performing' in Sidekiq without ever emitting [Captain V2] Agent result, while the client waited on WhatsApp. The runner.run() call never returned — presumably an HTTP hang on the LLM side (OpenAI slow, network flake, or retry storm inside ruby-llm). Post-hoc protections (tool_loop_detected, max_turns) can't fire because they only inspect result after run() returns. Adding a 45s hard timeout on the run() block guarantees we bail out, trigger bot_handoff, and respond to the client instead of hanging forever. Rescue Timeout::Error separately so the log message is specific and the user-facing message says "demorou mais do que o esperado". Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-04-19 11:40:59 -03:00
..
app	fix(captain): wrap runner.run in Timeout to guard HTTP hangs	2026-04-19 11:40:59 -03:00
config	feat: Conversation workflows(EE) (#13040)	2026-01-27 11:36:20 +04:00
lib	feat(lifecycle): inject concierge context into Captain orchestrator prompt	2026-04-15 09:25:16 -03:00
LICENSE	chore: update EE LICENCE year (#11344)	2025-04-21 15:29:55 +05:30
tasks_railtie.rb	fix: Search rake task causing Rails boot error (#12416)	2025-09-15 22:21:59 +05:30