Charles Bochet
a7324252fd
## Context Sentry issue [7438578272](https://twenty-v7.sentry.io/issues/7438578272/) (Logic Function Layer Build Failed, 7.9K events over 3 months): the yarn-install tool Lambda dies with `Runtime.OutOfMemory` / `signal: killed` while building an application's dependency layer. Every layer build for the affected application fails permanently, each database-event trigger re-attempts it, and one workspace produced ~2.5K events in the last week alone. ## Root cause The offending application declares `twenty-ui@1.0.0-alpha.0` (181MB unpacked, dragging in 141MB of `@tabler/icons*`) and dev tooling as production `dependencies` of server-side logic functions. Installing that tree needs just under 3GB during Yarn 4's fetch/link phase, so the 1024MB sandbox is OOM-killed. And even a successful install could never ship: AWS caps a function plus all its layers at 250MB unzipped. The user never sees any of this: the OOM is retried forever, and nothing tells them their dependencies are the problem. ## Fix 1. **Raise the yarn-install Lambda to 4096MB** so legitimate dependency trees install. Tool function names now include the memory/timeout/ephemeral-storage constants in their content hash, so a config change rotates the function name and the ensure path creates a fresh function with the new configuration — without this, the constant change would never reach already-deployed functions (their config is only applied at creation, and the ensure path early-returns when the function exists). 2. **Propagate Lambda's own errors to the user.** The install OOM (`Runtime.OutOfMemory` on the invoke) and the layer size rejection (`InvalidParameterValueException` at `PublishLayerVersion`) map to a new `LOGIC_FUNCTION_DEPENDENCIES_SIZE_EXCEEDED` code telling the user to move packages their logic functions don't import out of `dependencies`. Surfacing per API boundary: - **Sync / install (CLI)**: the workspace migration interceptor formats it into the same metadata validation error shape the SDK already renders, as one `logicFunction` entry carrying the remedy and the underlying AWS detail — no SDK rendering changes needed. - **`executeOneLogicFunction`**: mapped to `UserInputError` in the GraphQL handler. - **Route triggers**: HTTP 422 with the user-facing message, no Sentry capture. - **Background triggers**: skip instead of retrying, since no retry can succeed until the user changes their application. ## Test The error originates in AWS behavior, which CI (local driver, no AWS) cannot reproduce — so the chain is verified link by link: - **Real AWS, manual (not in CI)**: reproduced with the offending application's actual package.json against real Lambdas in the dev account — OOM-killed at 1024MB and 2048MB (exact prod error signature), install succeeds at 4096MB (~4min), and the resulting 292MB layer is rejected by `PublishLayerVersion` with the exact `InvalidParameterValueException` this PR matches. Same matrix reproduced in local cgroups beforehand. - **Server unit specs**: AWS error payload → exception mapping (`build-yarn-install-failure-exception`), exception → validation payload formatting (interceptor handler), `executeOneLogicFunction` GraphQL mapping, route filter 422 mapping, tool-function/layer name hashing. - **SDK integration spec (mocked server)**: runs the real `app dev` orchestrator on the minimal app with `syncApplication` mocked to return the validation-shaped failure, and asserts the CLI report renders the error code and remedy. It covers CLI rendering only — no test installs actual oversized dependencies, by design. - Docs updated (dependency size limits, sync failure taxonomy, route platform error responses).
80 lines
4.3 KiB
Plaintext
80 lines
4.3 KiB
Plaintext
---
|
|
title: Project Structure
|
|
description: What's inside a scaffolded Twenty app — files, folders, and what each one does.
|
|
icon: "folder-tree"
|
|
---
|
|
|
|
A new app generated by `npx create-twenty-app` looks like this:
|
|
|
|
```text filename="my-twenty-app/"
|
|
my-twenty-app/
|
|
package.json
|
|
src/
|
|
application-config.ts # Required — your app's entry point
|
|
default-role.ts # Permissions for logic functions
|
|
constants/
|
|
universal-identifiers.ts # Auto-generated UUIDs and metadata
|
|
front-components/
|
|
main-page.tsx # Welcome page component
|
|
navigation-menu-items/
|
|
main-page.navigation-menu-item.ts # Sidebar entry for the welcome page
|
|
page-layouts/
|
|
main-page.page-layout.ts # Standalone page hosting the component
|
|
__tests__/
|
|
application-config.test.ts # Unit test
|
|
global-setup.ts # Integration test setup (sync + uninstall)
|
|
schema.integration-test.ts # Integration test against a live server
|
|
.github/workflows/
|
|
ci.yml # Lint, typecheck, unit + integration tests
|
|
cd.yml # Deploy + install on push to main
|
|
publish.yml # Publish to npm on version tags (with provenance)
|
|
public/
|
|
logo.svg # Static assets
|
|
vitest.config.ts # Integration test runner config
|
|
vitest.unit.config.ts # Unit test runner config
|
|
tsconfig.json, tsconfig.spec.json
|
|
.nvmrc, .yarnrc.yml, .oxlintrc.json
|
|
README.md, AGENTS.md, CLAUDE.md, CHANGELOG.md, SETUP.md
|
|
```
|
|
|
|
## Key files
|
|
|
|
| File / Folder | Purpose |
|
|
|---|---|
|
|
| `src/application-config.ts` | **Required.** The main configuration file for your app. |
|
|
| `src/default-role.ts` | Default role controlling what your logic functions can access. |
|
|
| `src/constants/universal-identifiers.ts` | Auto-generated UUIDs and metadata (display name, description). |
|
|
| `src/front-components/`, `src/navigation-menu-items/`, `src/page-layouts/` | A starter welcome page: a front component rendered by a standalone page layout, reachable from the sidebar. |
|
|
| `src/__tests__/` | A unit test plus an integration test (with its global setup) that syncs the app against a real server. |
|
|
| `public/` | Static assets (images, fonts) served with your app. |
|
|
| `AGENTS.md` / `CLAUDE.md` | Guidance for AI coding agents working on the app. |
|
|
| `CHANGELOG.md` / `SETUP.md` | Changelog of notable changes and setup instructions for local development. |
|
|
|
|
<Note>
|
|
**File organization is up to you.** The folders above are conventions — the SDK detects entities via AST analysis on `export default defineEntity(...)` calls regardless of where the file lives.
|
|
</Note>
|
|
|
|
## Dependencies
|
|
|
|
Both Twenty SDK packages belong under `devDependencies`, not `dependencies`:
|
|
|
|
```json filename="package.json"
|
|
{
|
|
"dependencies": {},
|
|
"devDependencies": {
|
|
"twenty-client-sdk": "2.20.0",
|
|
"twenty-sdk": "2.20.0",
|
|
"twenty-ui": "1.0.0-alpha.1"
|
|
}
|
|
}
|
|
```
|
|
|
|
The scaffolder pins `twenty-sdk` and `twenty-client-sdk` to its own version — keep the two in sync when upgrading.
|
|
|
|
- **`twenty-sdk`** ships the `twenty` CLI and the build/scaffolding tooling. It only runs at development and build time and is never imported by your published app's runtime.
|
|
- **`twenty-client-sdk`** _is_ imported by your app code (`CoreApiClient`, `MetadataApiClient`, `RestApiClient`), but Twenty provides it at runtime — logic functions get it from a generated SDK layer, and front components resolve it from server-served modules. Your installed copy is only used for typechecking and the deploy-time build, so it never needs to ship in the deployed bundle.
|
|
|
|
Keeping either package under `dependencies` pulls it into the installed app's runtime bundle, where it is dead weight. `twenty dev:build` emits a warning when either is still listed under `dependencies`.
|
|
|
|
Add your app's own runtime dependencies (libraries your logic functions actually import at runtime) under `dependencies` as usual. Keep the tree lean: `dependencies` are installed into a runtime layer capped at 250MB unpacked, and a sync or install fails with a dependencies size error beyond that — UI libraries and dev tooling belong in `devDependencies`.
|