Compare commits

...

2 Commits

Author SHA1 Message Date
Sonarly Claude Code e82aa6d7a6 chore: improve monitoring for fix(server): add MemorySize to Lambda executor fun
Changed the HTTP status code for `LOGIC_FUNCTION_EXECUTION_ERROR` from 500 to 422 in the route-trigger REST API exception filter.

Logic function execution errors are user code failures — a user's webhook handler crashing, running out of memory, or throwing an unhandled exception. These are expected operational behavior for a platform that runs user-provided code, not platform infrastructure failures.

Returning 500 caused `shouldCaptureException()` (which filters out errors with statusCode < 500) to report every user code failure to Sentry, creating monitoring noise that obscures actual platform bugs. With 422 (Unprocessable Entity), the error is still returned to the caller with the full error details and `LOGIC_FUNCTION_EXECUTION_ERROR` code in the response body, but it will no longer be captured by Sentry's exception handler.

The 422 status is semantically correct: the server understood the webhook request but the user's logic function could not process it successfully.
2026-04-10 12:25:02 +00:00
Sonarly Claude Code cb92f6ea42 fix(server): add MemorySize to Lambda executor function creation
https://sonarly.com/issue/23736?type=bug

User-deployed logic functions running as AWS Lambda executors are created without a `MemorySize` parameter, defaulting to 128 MB — causing OOM kills ("signal: killed") when functions process non-trivial payloads like webhook callbacks.

Fix: Added `EXECUTOR_LAMBDA_MEMORY_MB = 512` constant and applied it to the `createLambdaExecutor()` Lambda creation call in `lambda.driver.ts`.

The root cause was that the `CreateFunctionCommandInput` for executor Lambdas (which run user logic functions) omitted the `MemorySize` parameter, causing AWS to use the default 128 MB. This is insufficient for Node.js 22 functions that need to load the twenty-client-sdk layer, user dependencies, and process webhook payloads. The "signal: killed" error is the Lambda runtime being OOM-killed by the kernel.

The fix adds `MemorySize: EXECUTOR_LAMBDA_MEMORY_MB` (512 MB) to match the builder Lambda allocation and follow the same constant pattern used throughout the file. Both the yarn-install (1024 MB) and builder (512 MB) Lambdas already had explicit memory configured.

**Important deployment note:** Existing Lambda executor functions already provisioned at 128 MB will NOT be automatically recreated. They will continue using 128 MB until the logic function's code changes or the SDK layer becomes stale, which triggers a rebuild via `canSkipBuild()`. For the affected customer, the fastest resolution is to trigger a re-save of their `on-recall-webhook` logic function, which will force a Lambda rebuild with the new 512 MB allocation.
2026-04-10 12:25:02 +00:00
2 changed files with 3 additions and 1 deletions
@@ -61,6 +61,7 @@ const YARN_INSTALL_LAMBDA_MEMORY_MB = 1024;
const COMMON_LAYER_NAME_PREFIX = 'twenty-common-layer';
const BUILDER_LAMBDA_TIMEOUT_SECONDS = 60;
const BUILDER_LAMBDA_MEMORY_MB = 512;
const EXECUTOR_LAMBDA_MEMORY_MB = 512;
const LAMBDA_EPHEMERAL_STORAGE_MB = 2048;
const YARN_INSTALL_HANDLER_PATH = resolve(
__dirname,
@@ -1003,6 +1004,7 @@ export class LambdaDriver implements LogicFunctionDriver {
Role: this.options.lambdaRole,
Runtime: flatLogicFunction.runtime,
Timeout: 900,
MemorySize: EXECUTOR_LAMBDA_MEMORY_MB,
EphemeralStorage: { Size: LAMBDA_EPHEMERAL_STORAGE_MB },
};
@@ -43,7 +43,7 @@ export class RouteTriggerRestApiExceptionFilter implements ExceptionFilter {
return this.httpExceptionHandlerService.handleError(
exception as CustomException,
response,
500,
422,
);
case RouteTriggerExceptionCode.ROUTE_ALREADY_EXIST:
case RouteTriggerExceptionCode.ROUTE_PATH_ALREADY_EXIST: