Fixes
https://twenty-v7.sentry.io/issues/7527156270?project=4507072499810304
## Problem
Sentry was flooded with high-severity alerts for logic functions that
simply ran too long:
> Lambda timed out for function '…' during invoke (functionState=Active,
phase=invoke …)
A function exceeding its configured `timeoutSeconds` is a **user-level
outcome** (their code is too slow), not a platform failure — but it was
being reported as one.
## Root cause
The two timeout mechanisms were classified inconsistently:
- **Lambda's own timeout** → returns `{ status: ERROR, … }` → handled as
a user error (route returns 500 with `shouldBeCapturedBySentry: false`,
queue job records it without failing). Not in Sentry. ✓
- **Client-side `AbortSignal` timeout** → **threw**
`LOGIC_FUNCTION_EXECUTION_TIMEOUT`, which isn't mapped in
`mapErrorToRouteTriggerCode`, so it fell through to
`ROUTE_TRIGGER_PLATFORM_ERROR` (Sentry) and failed the BullMQ job
(Sentry). ✗
Since the executor Lambda is fixed at 900s, the client abort is the
*sole* timeout enforcement for every function with `timeoutSeconds <
900` — so essentially every slow function paged the team. The `local`
driver already returns an ERROR result here; only the Lambda driver
threw.
## Fix
On an **invoke-phase** `TimeoutError`, return a structured ERROR result
instead of throwing — mirroring the Lambda's own timeout and the local
driver. The timeout now flows through the normal result path: surfaced
to the caller as `status: ERROR`, recorded via `handleExecutionResult`
(which the throw path skipped), and kept out of Sentry.
**Build- and fetch-phase timeouts still throw** and stay in Sentry —
those are platform-side (executor build / code fetch too slow, even for
short user code), which is exactly what the phase instrumentation exists
to catch.
## Tests
- Unit test on the new `buildLogicFunctionTimeoutResult` util
- `npx jest logic-function-drivers/drivers/lambda` green
Thomas Trompette
7a1cfc17cc