neiam
/apollos_crib
It's Apollo's Crib
public · Issues · Pulls 1 · Labels · Forks · Compare · Actions failure · Badges · Packages
⭐
Log in to mark this repository.
Give a vision's queries nearly the whole tick, not ten seconds
51f8710 · Gabriel Morell · 2026-09-02 16:15
Message
{commit_body(@commit)}
Files changed
modified
apps/room_sanctum/lib/room_sanctum/workers/vision_worker.ex
+13
−1
@@ -10,7 +10,19 @@ defmodule RoomSanctum.Worker.Vision do
| 10 | 10 | |
| 11 | 11 | # Each query is asked on its own, so this is the cap on one of them rather |
| 12 | 12 | # than on a round of them. |
| 13 | − @query_timeout_ms 10_000 | |
| 13 | + # | |
| 14 | + # Ten seconds was too tight and made things worse rather than safer. GTFS | |
| 15 | + # arrival lookups against prod's data take on the order of ten seconds -- the | |
| 16 | + # same slowness that used to blow the thirty second tick when a round asked | |
| 17 | + # three of them one after another -- so a ten second cap turned "sometimes | |
| 18 | + # completes" into "never completes", and every panel sat on its previous | |
| 19 | + # answer for ever. | |
| 20 | + # | |
| 21 | + # Just under the tick instead: a query gets essentially the whole interval, | |
| 22 | + # and the cap goes back to being a guard against a source that has genuinely | |
| 23 | + # hung rather than a limit real work runs into. It is not a fix for the | |
| 24 | + # slowness, which wants finding with an EXPLAIN against prod. | |
| 25 | + @query_timeout_ms 25_000 | |
| 14 | 26 | |
| 15 | 27 | # How many of a vision's queries may be out at once. |
| 16 | 28 | # |
Parents: b080da5