koala73 / koala73/worldmonitor
API 504: /api/intelligence/v1/deduct-situation — serverless timeout on situation-deduct/LLM path (WORLDMONITOR-VP)
- Dominant language
- TypeScript
- Stars
- 86.6k
- Forks
- 13.1k
- Avg merge
- 8h 4m
- Merged PRs (30d)
- 825
Description
## Summary
Low-volume but genuine backend signal surfaced during the 2026-07-10 Sentry event-volume review (the "too many errors?" pass that produced #5143). A user got **HTTP 504 (Gateway Timeout)** on `POST /api/intelligence/v1/deduct-situation`. Filing to track in case it recurs — **not urgent at current volume**.
## Evidence (Sentry WORLDMONITOR-VP)
- **2 events / 1 user**, both within a ~90s window: `2026-07-09 13:28:03 → 13:29:37Z`
- Release `worldmonitor@2.10.0`, `production`, Edge / Windows
- Breadcrumbs right before the failure show a `StrategicPosturePanel` situation load (military-vessel augmentation) — i.e. the user was running a situation analysis when the deduct call timed out.
- Sentry: https://elie-habib.sentry.io — search `WORLDMONITOR-VP`
## What a 504 here means
`/api/intelligence/v1/deduct-situation` deducts quota **and** runs the situation-analysis (LLM) work. A 504 is a platform **gateway timeout** — the serverless function exceeded its execution budget, almost certainly a slow upstream LLM call on that request. This is a latency/timeout tail, not a crash.
## Why it's low priority (for now)
- 2 events, 1 user, one ~90s burst — a single slow request, not a systemic outage (an outage would be many users / sustained).
- `level:error` overall is flat/normal (07-10 ≈ 11/day); this is not part of a regression.
## What to watch / investigate if it recurs
- [ ] Does VP re-fire across **multiple users or days**? (single-user one-off → close; broad/sustained → act)
- [ ] Function execution-time distribution for `deduct-situation` vs the platform timeout budget (Vercel function logs / duration p95–p99).
- [ ] Is the quota deduction **idempotent / ordered vs. the LLM call**? A 504 after a deduct-but-before-response could double-charge or leave an inconsistent ledger on client retry — worth confirming the deduct happens only on success (or is refunded on timeout).
- [ ] Consider an explicit server-side timeout + graceful 503/partial response on the LLM call so the client gets a clean, retryable error instead of a gateway 504.
## Disposition
Watch-only. Reassess if it re-fires beyond a single user/session.
_Filed from the #5143 Sentry-noise-review session._
Contributor guide
Research direction
Start at the POST /api/intelligence/v1/deduct-situation entry point and review Vercel function duration logs against the platform timeout budget. Investigate whether quota deduction is ordered safely around the LLM call and whether the event recurs across users or days; done means establishing whether this remains watch-only or needs a defined timeout and retry-handling change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend, cloud
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100