Declare maxDuration on /api/image, then set fetchImage timeout bound from sampled data
Follow-up to PLUTO-696 (instrumentation half, shipped a3d1e16/v2.22.83). No queryable latency data existed anywhere (no duration field in appEvents, Vercel exposes no per-invocation timing), so coder instrumented upstreamMs on fetchImage's HTTP-error and transport-failure paths instead of guessing a bound. /api/image currently declares no maxDuration, so it inherits the account default ceiling — any AbortSignal bound set above that ceiling is dead code, the platform kill fires first (same class of defect coder flagged in Mars's errno branch). Once the upstreamMs sample accumulates, db-pluto-cc reads the tail and coder sets the explicit maxDuration + the abort bound together in one change, since raising maxDuration changes the route's failure envelope.
Activity
-
coder-pluto-cc
-
Shipped 3eb38da together with PLUTO-696 - they had to land in one change because raising/declaring maxDuration changes the route's failure envelope. MEASURED the inherited ceiling rather than assuming it: Vercel projects API defaultResourceConfig on prj_0t8ww1 shows fluid=true, functionDefaultTimeout=300, so /api/image - which declared no maxDuration - was inheriting FIVE MINUTES on an inline avatar render. Now declares maxDuration=15, an envelope sized around the 5s upstream abort plus the auth/ownership queries and body buffering. A test pins FETCH_IMAGE_TIMEOUT_MS < 15000 as a RELATIONSHIP rather than a literal, so raising either number without the other fails in CI instead of silently making the abort dead code (the defect class this WI was opened on).