257 Commits

Author	SHA1	Message	Date
Charles Bochet	6e30405489	Bump vulnerable dependencies flagged by ECR image scanning (#23813) ... ## Context The Oneleet monitor **"AWS ECR repository image vulnerabilities are remediated"** is alerting on `prod-twenty` images: 1 CRITICAL + 6 HIGH advisories breach their SLA in 7 days, plus a set of MEDIUMs. All of them are npm packages baked into the image. ## Changes | Package | Before | After | How | Advisories | |---|---|---|---|---| | undici | 7.28.0 / 6.27.0 | 8.9.0 | jsdom `^30` bump + node-gyp refresh; global `undici: ^8.9.0` resolution for @module-federation/dts-plugin, e2b and miniflare, which still pin 7.28.0 at latest (replaces the old scoped dts-plugin resolution) | CVE-2026-13697 (critical), CVE-2026-14643, CVE-2026-15157/16728/16729 | | sharp | 0.34.5 | 0.35.3 | direct bump in twenty-sdk; @argos-ci refresh; `next/sharp` resolution (next 16.3.0 with the fix is still quarantined by yarn's minimal-age gate) | GHSA-f88m-g3jw-g9cj | | axios | 1.17.0 | 1.19.0 | lockfile refresh | GHSA-gcfj-64vw-6mp9 + 10 medium | | ip-address | 10.2.0 | 10.4.0 | lockfile refresh | CVE-2026-69192, CVE-2026-54272, CVE-2026-69198 | | brace-expansion | 2.1.2 | 2.1.4 | lockfile refresh (backport exists; Inspector only lists 5.x) | CVE-2026-69152, CVE-2026-14257, CVE-2026-13149 | | typeorm | 0.3.29 | 0.3.31 | pin bump; the local yarn patch applies unchanged | GHSA-2rp8-mm9q-fp49 | ## Validation - `yarn.lock` contains no remaining vulnerable versions (undici resolves only to 8.9.0) - `yarn npm audit`: no remaining advisories among the bumped packages - `nx build` green for twenty-server, twenty-front (exercises module-federation dts-plugin on undici 8), twenty-sdk, twenty-website; twenty-server typecheck green (typeorm patch is type-level) - Runtime smoke: jsdom 30 DOM parse, sharp 0.35.3 png encode, undici 8.9.0 load ## Not covered - **react-router / react-router-dom 6.30.4** (medium, 1–3 month SLA): react-router-dom 6.x has **no fixed release**; the fix is the v7 migration (~225 files) — separate effort. - `prod-business-dash` body-parser 2.2.2 → 2.3.0 lives in its own repo. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23813?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-08-05 14:42:43 +00:00
Paul Rastoin	eb69e56441	[Upgrade] Add a detached-run wrapper for the upgrade command (#23497) ... Long upgrades are started over `kubectl exec` into the command-runner pod, where the process is a child of the exec'd shell: a dropped SSM tunnel, a closed laptop or a dead VPN kills the run mid-way. There is no tmux in the image (Alpine, `sh: tmux: not found`). `scripts/upgrade-background.sh` puts the run in its own session with no controlling terminal and streams its output from a log file, so losing the connection detaches the stream instead of killing the upgrade. Builds on #23481. The cooperative shutdown path is untouched, this is tooling around it. No TypeScript changed. ## Commands ```bash yarn upgrade:background [args] # start detached, then stream the log yarn upgrade:background:logs # re-attach from another shell yarn upgrade:background:stop # graceful stop; --now immediate, --force SIGKILL ``` `[args]` is forwarded verbatim to `upgrade`, so it takes that command's options and no others: | Option | Effect | | --- | --- | | `-d`, `--dry-run` | simulate without making changes | | `-v`, `--verbose` | verbose output | | `-w`, `--workspace-id <id>` | restrict to a workspace, repeatable; all provisioned workspaces if omitted | | `--start-from-workspace-id <id>` | resume from a workspace, ascending id order | | `--workspace-count-limit <n>` | process at most n workspaces, ascending id order | `-w` and `--start-from-workspace-id` are mutually exclusive, `upgrade` rejects the combination. ## Example ```ts ➜ twenty-server git:(claude/upgrade-detached-run-wrapper-5nkb0v) ✗ yarn upgrade:background Running (pid 15779), logging to /tmp/twenty-upgrade.log Ctrl+C detaches the stream only. Use 'yarn upgrade:background:stop' to stop the run. ^C% ➜ twenty-server git:(claude/upgrade-detached-run-wrapper-5nkb0v) ✗ yarn upgrade:background:stop SIGTERM sent to 15779, it finishes the step in progress then stops (exit 143) Tail of /tmp/twenty-upgrade.log: [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on FieldMetadataEntity: standardOverrides,isCustom [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] applied cursor=217 renamed=0 unavailable=0 hiddenColumns=5 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on RolePermissionFlagEntity: flag [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on ObjectMetadataEntity: standardOverrides,isCustom [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on FieldMetadataEntity: standardOverrides,isCustom [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] applied cursor=207 renamed=0 unavailable=0 hiddenColumns=5 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [DatabaseConfigDriver] [INIT] Loading initial config variables from database [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [DatabaseConfigDriver] [INIT] Config variables loaded: 1 values found in DB, 104 falling to env vars/defaults [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeCommand] Initialized upgrade sequence: 217 step(s) [upgrade] event=sequence.initialized stepCount=217 dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceIteratorService] Running on workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 1/2 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceCommandRunnerService] Upgrading workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 1/2 [upgrade] event=workspace.start workspaceId=20202020-1c25-4d02-bf25-6aeccf7ea419 index=1 total=2 dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceCommandRunnerService] Upgrade for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 completed. [upgrade] event=workspace.success workspaceId=20202020-1c25-4d02-bf25-6aeccf7ea419 executedByVersion=unknown dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceIteratorService] Running on workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db 2/2 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceCommandRunnerService] Upgrading workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db 2/2 [upgrade] event=workspace.start workspaceId=3b8e6458-5fc1-4e63-8563-008ccddaa6db index=2 total=2 dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [DummySleepCommand] Sleeping for 30000ms on workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db [Nest] 15779 - 07/30/2026, 10:47:53 AM WARN [CommandShutdownService] Received SIGTERM, finishing the step in progress then stopping. Send SIGTERM again to exit immediately. Follow with 'yarn upgrade:background:logs'. Still stuck: 'stop --now'. Last resort: 'stop --force'. ➜ twenty-server git:(claude/upgrade-detached-run-wrapper-5nkb0v) ✗ yarn upgrade:background:stop --now Second SIGTERM sent to 15779, immediate exit with the step in progress left unfinished Tail of /tmp/twenty-upgrade.log: [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on RolePermissionFlagEntity: flag [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on ObjectMetadataEntity: standardOverrides,isCustom [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] hidden columns on FieldMetadataEntity: standardOverrides,isCustom [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeAwareEntityMetadataAdapter] [upgrade-metadata] applied cursor=207 renamed=0 unavailable=0 hiddenColumns=5 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [DatabaseConfigDriver] [INIT] Loading initial config variables from database [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [DatabaseConfigDriver] [INIT] Config variables loaded: 1 values found in DB, 104 falling to env vars/defaults [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [UpgradeCommand] Initialized upgrade sequence: 217 step(s) [upgrade] event=sequence.initialized stepCount=217 dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceIteratorService] Running on workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 1/2 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceCommandRunnerService] Upgrading workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 1/2 [upgrade] event=workspace.start workspaceId=20202020-1c25-4d02-bf25-6aeccf7ea419 index=1 total=2 dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceCommandRunnerService] Upgrade for workspace 20202020-1c25-4d02-bf25-6aeccf7ea419 completed. [upgrade] event=workspace.success workspaceId=20202020-1c25-4d02-bf25-6aeccf7ea419 executedByVersion=unknown dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceIteratorService] Running on workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db 2/2 [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [WorkspaceCommandRunnerService] Upgrading workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db 2/2 [upgrade] event=workspace.start workspaceId=3b8e6458-5fc1-4e63-8563-008ccddaa6db index=2 total=2 dryRun=false [Nest] 15779 - 07/30/2026, 10:47:50 AM LOG [DummySleepCommand] Sleeping for 30000ms on workspace 3b8e6458-5fc1-4e63-8563-008ccddaa6db [Nest] 15779 - 07/30/2026, 10:47:53 AM WARN [CommandShutdownService] Received SIGTERM, finishing the step in progress then stopping. Send SIGTERM again to exit immediately. [Nest] 15779 - 07/30/2026, 10:48:00 AM WARN [CommandShutdownService] Received SIGTERM again, exiting immediately. The step in progress is left unfinished, rerun the command to resume from the last recorded step. EXIT=143 ``` ## Not a concurrency guard `start` refuses when it can see a live run, but that only keeps this wrapper's own bookkeeping straight, one PID file and one log per run. The PID file is in the container's `/tmp`, so a second pod or a laptop pointed at the same database sees none of it. Nothing in `upgrade` prevents two sequences either: `upgradeMigration` records only `completed` and `failed`, so it has no in-progress state to lock against, and the sequence runner takes no advisory lock. Out of scope here, and worth a follow-up if we want it enforced rather than operational. ## Dockerfile `scripts/` was not copied into the server image, so all three commands would have failed with ENOENT in the pod. Added the COPY, plus a `chmod +x` matching the one already on `entrypoint.sh`. Rest is documented in `docs/UPGRADE_COMMANDS.md`, including the exit-code table and why a graceful stop is always safe to rerun.	2026-07-30 12:24:07 +00:00
BOHEUS	a3b54e834c	PDF upload fix (#23473) ... Sometimes uploading PDF files resulted in "Non-whitespace before first tag." error, updating parsing library fixes the error <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23473?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-29 09:16:29 +00:00
Guillaume Flambard	710d4da4b1	fix(emails): bump @react-email/render to ^2.0.6 to fix empty transactional email bodies (#23323) ... ## Problem Fixes #23307. Every transactional email (workspace invite, password reset, email verification, etc.) is delivered with an **empty body** — no title, text, or CTA. ## Root cause `twenty-server` pins `@react-email/render` directly at `^1.2.3`: ```jsonc // packages/twenty-server/package.json "@react-email/render": "^1.2.3", ``` In 1.2.3, `render()` reads `renderToReadableStream` **before** the email template's async Suspense boundary (i18n/locale load) has resolved. The result is the Suspense fallback marker instead of the real markup: ```html <!DOCTYPE html ...><!--$!--><template></template><!--/$--> ``` This was fixed upstream in `@react-email/render@2.0.6` (*"await stream.allReady before reading renderToReadableStream output"*). `twenty-emails` already resolves a 2.x render via `react-email@6.5.0`, so the server's direct pin was simply stale — the two were out of sync. ## Fix Bump the direct pin to `^2.0.6` (resolves to `2.1.0`) and regenerate the lockfile. The server's `render()` imports now use the fixed 2.x. > Note: a `1.2.3` entry remains in `yarn.lock` — it is an internal transitive > pin of `@react-email/components@0.5.3`, not the server render path, so it is > expected and harmless. ## Verification Rendering `SendInviteLinkEmail` through the real `render()` (Node 24) now returns full markup (5.7 kB) with no Suspense marker and the resolved invite link + workspace content, instead of the empty fallback. A jest unit test was intentionally not added: `@react-email/render` 2.x uses a dynamic import that jest's CJS runtime rejects ("A dynamic import callback was invoked without --experimental-vm-modules") — which is exactly why the existing email specs mock `render`. The fix was verified with a standalone Node script. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/23323?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Félix Malfait <felix.malfait@gmail.com>	2026-07-27 11:37:09 +02:00
martmull	dcccdbd148	Fix flaky "read EINVAL" in integration tests: bump msw to 2.12.14 (#22702) ... # Context Part of a CI flakiness sweep. Integration shards are intermittently killed by an uncaught socket error that poisons a whole spec file (e.g. `sync-failure-lifecycle.integration-spec.ts`, 4 tests, on unrelated PR branches — example run 28940565117, shard 8): ``` Error: read EINVAL at MockHttpSocket.emit (@mswjs/interceptors/.../MockHttpSocket.ts:161) ``` # Root cause The integration setup routes **all** HTTP (including supertest/node-fetch calls to the in-process app) through msw's ClientRequest interceptor, with localhost passthrough. msw `2.12.7` pins `@mswjs/interceptors` `0.40.0`, where: - `passthrough()` aliases the real socket's libuv `_handle` onto the mock socket (two owners of one handle) and forwards the real socket's `error` events into `MockHttpSocket.emit`, - `destroy()` never destroys the passthrough socket, so it stays orphaned with its error-forwarding listener attached. When the server side closes such a connection later, a read on the stale shared handle yields `EINVAL`, forwarded into `emit()` with no request (and no error listener) attached → uncaught exception → jest kills the in-flight file. This is upstream [mswjs/interceptors#753](https://github.com/mswjs/interceptors/issues/753); the stack frames match line-for-line. # Fix Bump `msw` to **exactly `2.12.14`** in `twenty-server` and `twenty-front` (shared lock entry). msw 2.12.9+ requires interceptors `^0.41.2` → resolves 0.41.9, which ships [interceptors#755](https://github.com/mswjs/interceptors/pull/755): passthrough sockets get their listeners removed and are destroyed on close, severing the exact error path above. Notes from adversarial review: - Pinned exact (`2.12.14`, not `^`) because the caret would resolve to 2.15.0 today — a bigger jump than reviewed. - Compatibility checked: no deep imports of msw/interceptors anywhere; interceptors 0.41.x externals already covered by `transformIgnorePatterns`; `msw-storybook-addon@2.0.6` peer range satisfied; `mockServiceWorker.js` integrity checksum unchanged between 2.12.7 and 2.12.14; 0.41.7+ adds Node 24 compatibility (repo targets Node 24). - Residual risk disclosed: #753 is still open upstream and the `_handle` aliasing remains in 0.41.9 — this removes the observed orphaned-socket path, but keep an eye out for recurrence. Dependency-only change: 2 package.json lines + lockfile. --- _Generated by [Claude Code](https://claude.ai/code/session_01AtD2wWm3EthV6t3Hs31QyB)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22702?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-09 10:58:26 +02:00
neo773	d99e6db93d	test(messaging): messaging and calendar sync integration suites (#22567) ... 13 integration suites driving the real sync pipeline end to end — OAuth connect via the actual `/auth/google-apis/get-access-token` / `microsoft-apis` callbacks (transient token + mocked provider token exchange), real queue workers, provider APIs mocked at the HTTP layer with msw. **Messaging (8):** Gmail list fetch + import, Gmail folder discovery, Microsoft folder discovery, history-based incremental sync, stale-sync recovery, sync failure lifecycle (429 throttle → exhaustion → relaunch; declined refresh token → insufficient permissions), token refresh, connected-account cleanup cascade. **Calendar (5):** Google events import (full + sync-token incremental), Microsoft events import (delta fetch + import), stale-sync recovery, failure lifecycle, cleanup cascade. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22567?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-07 18:38:05 +05:30
martmull	1a85b88d38	feat(files): direct-to-storage upload endpoints with pending file lifecycle (#22449) ... <img width="1484" height="404" alt="image" src="https://github.com/user-attachments/assets/b2d363bf-d9e1-49fb-9811-8cc98041aa79" /> ## Context Uploading large files currently OOMs the server: every upload resolver buffers the whole file in memory (`streamToBuffer`) before writing it to storage. This PR is the first of a series introducing direct client-to-storage uploads. It adds the server-side endpoints and driver support only — it is non-breaking and nothing consumes the new flow yet. Follow-up PRs will migrate the frontend upload paths, add a stale-pending-file cleanup cron, and cap the legacy buffered resolvers. ## What it does **New upload flow (initiate → PUT → confirm):** - `createFileUpload(filename, size, fileFolder, fieldMetadataId?)` validates the request (folder allowlist: `FilesField`/`Workflow`, max size, extension-derived mime type), creates the file record in a new `PENDING` status, and returns an upload target: - **S3 with presign enabled** → a presigned PUT URL with `Content-Type`/`Content-Length` pinned in the signature, so the client uploads straight to the bucket; - **local storage, or S3 without presign** → a token-authenticated streaming endpoint on the server (`PUT /file-upload/:id?token=…`, new `FILE_UPLOAD` JWT type) that pipes the request body to the storage driver with constant memory usage and a declared-size cap. - `completeFileUpload(fileId)` verifies the bytes actually landed in storage (HEAD + size match against the declared size) and flips the record to `UPLOADED`. Idempotent. **Pending lifecycle safety:** - New `status` column on `core.file` (`PENDING`/`UPLOADED`, default `UPLOADED` so all existing rows and the legacy upload path are unaffected) + fast instance command. - Files are refused by the serving endpoints and by FILES-field sync while `PENDING`. **Driver support (both drivers):** - `getPresignedUploadUrl` (S3: presigned PUT; local: `null` → server-endpoint fallback) - `writeFileStream` (local: `fs` pipeline with the existing symlink/containment hardening, partial-file cleanup on error; S3: `@aws-sdk/lib-storage` `Upload` for bounded-memory streaming) - `getFileMetadata` (HEAD/stat for confirm-time verification) ## Tests - `file-upload.service.spec.ts`: initiate validation (folder allowlist, size), presigned vs fallback target, confirm verification (missing object, size mismatch, happy path, idempotency) - `local.driver.spec.ts`: `writeFileStream` (content, symlink rejection, partial-file cleanup on stream error), `getFileMetadata` - `s3.driver.spec.ts`: `getPresignedUploadUrl` (disabled → null, PUT command with signed content-type/content-length) - `direct-file-upload.integration-spec.ts`: full end-to-end flow against the local driver (initiate → PUT → complete → download), plus error paths (complete without upload, oversized PUT → 413, invalid token → 403, unsupported folder, size above max) ## Notes for reviewers - The upload-size ceiling for direct uploads is `settings.storage.maxDirectUploadFileSize` (1GB), separate from the 10MB `maxFileSize` used for pictures. - Since content can't be sniffed before it reaches storage, the mime type is derived from the file extension (with the existing `TWENTY_MIME_POLICY` override) and unknown extensions fall back to `application/octet-stream`; the serving path already forces `Content-Disposition: attachment` for anything not on the inline-safe allowlist. - Self-hosters using S3 presign will need a bucket CORS policy allowing `PUT` from the frontend origin (config variable description updated). https://claude.ai/code/session_015UH8KWmsB9zdYaog8MFG1d --- _Generated by [Claude Code](https://claude.ai/code/session_015UH8KWmsB9zdYaog8MFG1d)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22449?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-07-03 15:11:53 +02:00
Félix Malfait	538b180824	feat(dpa): self-serve Data Processing Agreement generator (#22243) ... ## What A single, region-aware DPA that serves all customers, generated automatically from the customer's deployment. Two layers: 1. **Click-through DPA** — recorded at signup (acceptance = execution), resolving merge fields from the deployment region. Cloud only. 2. **In-app signed-PDF generator** — Settings → Legal → Generate DPA: preview the agreement, enter legal entity + authorized signatory, download a PDF pre-signed by Twenty, and store the executed copy against the workspace with its template version + timestamp. Deep-linkable at `/dpa` (login-gated) for `twenty.com/dpa`. ## How it resolves A typed variable matrix (`dpa-region-config.constant.ts`) maps the deployment region to the contracting Processor entity and terms: - **EU (default)** → Twenty.com SAS, hosting EU/Frankfurt, governing law France, SCC section dormant. - **US (custom)** → Twenty, Inc., hosting US, SCC section active. Region is a deployment-wide setting (`DPA_DEPLOYMENT_REGION`, default EU) behind a `DpaRegionService` seam so it can later become per-workspace without touching callers. The legal text is verbatim from the template (generated into `dpa-template.constant.ts` directly from the source `.docx`); only the 6 merge fields are filled and the SCC sections (7.2–7.5) stay in the document for every region per the spec — only field values branch. Sub-processors are deferred to trust.twenty.com (not enumerated). Billing stays decoupled (Twenty, Inc. remains merchant of record regardless of Processor). ## UI Standard list + create-page pattern (mirrors API keys / webhooks): a list of executed copies (with re-download) — or the agreement preview when none exists — and a top-right blue **Generate DPA** CTA opening a standard create page. The "Legal" item is intentionally **not** in the settings menu; the page is reached via the `/dpa` deep link. ## Notable implementation details - **PDF** is rendered server-side with `@react-pdf/renderer`. The built-in standard-14 fonts only encode ASCII and crash on the template's curly quotes / em–en dashes / accented Latin, so Liberation Sans (OFL) is **subset to a Latin glyph set and embedded as base64 data: URLs** — no font files to ship or resolve at runtime (works in dev, prod-Docker and CI). - New `core.dpaAgreement` table via a fast instance command (FK hash reproduced to match TypeORM). - Self-hosted deployments (billing disabled) skip click-through recording and stamp a prominent "not a valid agreement" banner on the preview and PDF. ## Tests - Unit: resolver (per-region entity/law/SCC state, EU default, no unresolved `{{ }}`, SCC sections present in both regions, self-hosted notice) and HTML renderer. - Integration (`test/integration/graphql/suites/dpa`): preview has no unresolved fields; `generateSignedDpa` renders + persists + returns a downloadable PDF (asserted with accented input to guard the font regression); list re-download. ## ⚠ Needs legal input before go-live (marked `TODO_CONFIRM` in `dpa-region-config.constant.ts`) - Registered-office addresses for Twenty.com SAS and Twenty, Inc. - US deployment governing law (the template only specifies France). - DPO name and the Twenty pre-signed authorized signatory name/title. ## Out of scope (flagged per spec) Intra-group legal agreement and any Stripe/billing-entity changes. A future e-sign provider would plug in at `DpaService.generateSignedDpa` + the signatory input. > Draft until the integration test passes in CI and the legal `TODO_CONFIRM` values are supplied. https://claude.ai/code/session_01Ahjydxx6J1souz1s1NeA9a --- _Generated by [Claude Code](https://claude.ai/code/session_01Ahjydxx6J1souz1s1NeA9a)_ <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22243?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-27 17:46:38 +02:00
Félix Malfait	0e22ae0521	feat: create calendar events on Google and Microsoft accounts (#22231) ... ## Context Twenty can import calendar events and send emails, but cannot create calendar events. This adds calendar event creation on connected **Google** and **Microsoft** accounts, mirroring the existing email-send architecture (`message-outbound-manager`). ## What it adds The capability is exposed three ways, all backed by the same composer → driver → persist pipeline: - **GraphQL mutation** `createCalendarEvent` (metadata API) - **AI agent tool** `create_calendar_event` (flows to MCP automatically), gated by a new `CREATE_CALENDAR_EVENT_TOOL` permission flag - **Workflow builder node** "Create Calendar Event" in the **Core** section, with a full settings form (variable interpolation supported) CalDAV/IMAP is intentionally out of scope for now (different long pole). ## Design notes - **Reuse over reinvention** — the created event is run through the existing inbound formatters (`formatGoogleCalendarEvents` / `formatMicrosoftCalendarEvents`) and persisted immediately via the existing `CalendarSaveEventsService`, so it appears in Twenty right away and is reconciled by the next provider sync (dedup on external id). Persistence is best-effort. - **OAuth scopes** — Google already requests `calendar.events` (read+write), so no change there. Microsoft moves `Calendars.Read` → `Calendars.ReadWrite`; existing Microsoft accounts must re-consent (surfaced as a clear "reconnect" error via a missing-scope check). - **Deliberate invitation semantics** — `sendInvitations` is off by default. When off, the event is created with **no attendees** on either provider, so creating an event never silently emails external people. When on, attendees are attached and notified (Google `sendUpdates: all`, Microsoft's default). This sidesteps Microsoft Graph having no per-request suppression. - **Timezone correctness** — Microsoft Graph interprets `dateTime` as wall-clock in the supplied `timeZone` and ignores the offset, so the absolute instant is converted to its wall-clock form before sending (Google honors the offset directly). Both providers end up scheduling the same instant. - **Conferencing** — optional Google Meet (`conferenceData.createRequest`, with a follow-up `events.get` to resolve the async link) / Microsoft Teams (`isOnlineMeeting`). - Attendees are a comma-separated string everywhere (tool input, GraphQL DTO, workflow input), consistent with `send_email` recipients; the composer parses to its internal list. ## Test plan - **Unit**: 45 tests covering the composer (validation, all-day boundaries, offset enforcement, timezone, scope checks, default-account resolution), both provider drivers, the dispatcher, and the workflow step-log builder. - **Integration**: `createCalendarEvent` on the `/metadata` API fails closed with a structured error for a non-existent account (the auth/ownership/validation path that doesn't require provider mocking). - **Manual**: verified the workflow node appears in the Core section, the settings form renders and round-trips (edit → autosave → reload), and the live mutation returns a structured failure for a bogus account. ## Open question for reviewers The metadata mutation `createCalendarEvent` shares a name with the core schema's auto-generated `createCalendarEvent(data:)` CRUD mutation for the CalendarEvent object — they live on different endpoints (`/metadata` vs `/graphql`) so there's no runtime conflict, but it's a potential point of confusion for API consumers. Happy to rename (e.g. `createCalendarEventOnConnectedAccount`) if preferred. ## Out of scope / follow-ups - CalDAV/IMAP support - Event update/delete and recurrence - Existing Microsoft accounts need re-consent for the widened scope <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22231?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: neo773 <neo773@protonmail.com>	2026-06-27 14:05:58 +02:00
Etienne	0f4c4e69a9	fix(ai-tool): make search_output a raw-text occurrence search (#22034) ... ## Summary `search_output` (the spilled-output navigation tool) was built around a JSON-centric, line-based model that breaks for the data it actually receives. Spilled outputs are written as compact `JSON.stringify(output)` (single line, escaped newlines), so the tool's line-by-line matching collapsed to at most one match, and its schema described searching "the indented JSON representation" even though it falls back to raw text for non-JSON. It also ran arbitrary, model-supplied regexes through the native engine with no ReDoS protection. This reworks the tool into a `grep -o` style search over the raw file bytes: it finds every occurrence of a pattern regardless of newlines and returns a character window around each hit. It works uniformly for compact/pretty JSON, CSV, HTML, and plain text. ## Changes - **Occurrence-based matching** (`search-output.util.ts`): search the raw content for every match via a global-regex `exec` loop (with a zero-width-match guard), bounded by `offset + maxMatches`. Results are now `{ charOffset, match, context }` with a character window around each occurrence and a centered-ellipsis cap for very long single matches. The line model (`split`, line numbers, line context) is removed. - **ReDoS hardening**: matching now uses `re2` (already a dependency) with the global flag, guaranteeing linear-time matching. Unsupported regex features (lookahead/backreferences) and invalid patterns fall back to escaped-literal search instead of throwing. - **No more reserialization** (`search-output-tool.ts`): the `JSON.stringify(JSON.parse(...))` round-trip is gone; the tool searches the exact bytes on disk, so there is no coordinate divergence with `extract_json_paths`. - **API** (`search-output-tool.schema.ts`): `contextLines` → `contextChars` (default 100, max 2000); honest descriptions reflecting raw-text occurrence search and the regex-or-literal fallback. The result message reports occurrence counts. - **Cleanup**: removed unused constants (`default-search-output-context-lines`, `search-output-max-line-length`); added `default-search-output-context-chars` and `search-output-max-match-length`. `extract_json_paths` and the spill service are untouched. ## Tradeoff Results use character offsets/windows rather than line numbers and line context. For an LLM extracting values from a spilled blob this is more robust (works on single-line content); the cost is no line-based context for genuinely line-structured content. ## Test plan - [x] `search-output.util.spec.ts` rewritten for occurrence semantics: multiple hits on a single newline-free line, zero-width-pattern termination, catastrophic-backtracking pattern stays fast (RE2), lookahead/invalid-regex literal fallback, char-window clipping, offset pagination, long-match truncation. 12/12 pass. - [x] `npx nx typecheck twenty-server` clean. - [x] `npx nx lint:diff-with-main twenty-server` clean (lint + format). ## Deploy note `re2` is a native addon. It was declared in `package.json` but never imported/built before this PR, so its binary may be absent in some environments (local install required `npm rebuild re2`). Confirm the install/build pipeline (CI, Docker images) compiles native modules so the tool doesn't throw `Cannot find module 're2.node'` at runtime. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/22034?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-23 17:18:46 +00:00
Abdullah.	6520db22ca	fix(deps): bump opentelemetry suite to core 2.8.0 (+ sentry 10.59) (#22010) ... ## Summary Bumps the OpenTelemetry suite onto the **`@opentelemetry/core` 2.8.0** wave (plus Sentry `10.51 → 10.59`, which carries the otel instrumentation), resolving [Dependabot alert #1510](https://github.com/twentyhq/twenty/security/dependabot/1510) (`@opentelemetry/core < 2.8.0`). ## Why a parent-bump, not a `resolutions` entry The vulnerable `@opentelemetry/core` is transitive, pulled in by the otel packages we declare (`exporter-metrics-otlp-http`, `exporter-prometheus`, `sdk-metrics`) **and** by `@sentry/*` (which bundles `@opentelemetry/instrumentation-*`). The otel **stable** packages pin `core` to their own exact version and are version-coupled — forcing `core` ahead of the suite via `resolutions` risks runtime breakage. So this bumps the declared parents instead. ## Changes - `twenty-server/package.json`: - `@opentelemetry/exporter-metrics-otlp-http` `^0.200.0 → ^0.219.0` - `@opentelemetry/exporter-prometheus` `^0.217.0 → ^0.219.0` - `@opentelemetry/sdk-metrics` `^2.0.0 → ^2.8.0` - `@sentry/{nestjs,node,profiling-node}` `^10.51.0 → ^10.59.0` - `yarn dedupe` collapses the remaining transitive `core@2.7.1` (caret consumers) onto `2.8.0` — the whole stable set (`core` / `resources` / `sdk-trace-base` / `sdk-metrics`) is now `2.8.0`. - **`@types/pg` added as a direct devDependency.** The newer Sentry drops the instrumentation that used to *transitively* provide `@types/pg`; twenty-server imports `pg` directly (`set-pg-date-type-parser.ts`), so it now declares its own types — fixing a latent fragility the bump exposed. ## Verification - `nx typecheck twenty-server` — **0 errors** (validates the otel/sentry API surface we call is intact). - `yarn install --immutable` passes. - No `@opentelemetry/core < 2.8.0` remains. - Lockfile churn is contained to the observability subtree (otel/sentry + their transitive deps; net **−615 lines**). > Sentry resolved to `10.59.0` rather than the just-published `10.60.0` due to the repo's `npmMinimalAgeGate`. > Worth a quick server-boot check during review to confirm Sentry/otel init at runtime.	2026-06-23 17:32:41 +05:00
Etienne	7b45380777	feat(ai): large tool output handling + navigation tools (#21982) ... ## Summary Large tool outputs (e.g. a workflow run that serializes to ~70k tokens) blow the chat context budget and force per-tool "raw" variants. This PR handles oversized outputs generically in one place: 1. **Producer:** when a tool result exceeds a byte budget, it is spilled to a `FileFolder.AgentChat` file and replaced with a compact `{ spilled, outputRef, shape, hint }` envelope. 2. **Consumer:** two bounded, in-server navigation tools — `extract_json_path` and `search_output` — let the model dig into the spilled file by `fileId` without spinning up `code_interpreter`. Together they add a fast, auditable middle tier between "truncated inline preview" and "full code_interpreter relay," and enable an enterprise "restricted" mode (spill + navigation, no sandbox). ## Data flow ```mermaid flowchart TD exec["resolveAndExecute / hydrateToolSet closure"] --> compact[compactToolOutput] compact --> enabled{"spillLargeOutput enabled? (chat only)"} enabled -->|no| inlineRaw["inline raw (MCP, workflow, sandbox bridge)"] enabled -->|yes| size{"bytes > MAX_INLINE_TOOL_OUTPUT_BYTES?"} size -->|no| inline["inline result"] size -->|yes| skeleton["jsonShapeSkeleton + largeOutputHint"] skeleton --> write["writeFile(AgentChat)"] write --> envelope["return { spilled, outputRef, shape, hint }"] envelope --> model[Model] model --> nav["extract_json_path / search_output / code_interpreter (by fileId)"] ``` ## Part 1 — Navigation tools (consumer) - `extract_json_path`: extracts a sub-tree from a spilled JSON file by a JSONPath-lite expression (dot/bracket access, array slicing, single-level wildcard), with `maxItems`/`maxDepth` bounding. No filters or recursive descent — those belong to `code_interpreter`. - `search_output`: grep-like line search with context lines and stateless `offset` pagination (`{ matches, totalMatches, hasMore }`). - Both read from `FileFolder.AgentChat` by `fileId`, enforce their own output byte cap, and are registered in `ActionToolProvider` (always available; read-only). ## Part 2 — Spill producer - Spilling slots in right after the existing `compactToolOutput` step at the two seams in `ToolRegistryService` (`resolveAndExecute` and the `hydrateToolSet` execute closure). - `ToolOutputSpillService.spillIfTooLarge()` measures `Buffer.byteLength`; over `MAX_INLINE_TOOL_OUTPUT_BYTES` (16 KB ≈ 4k tokens) it writes the full payload and returns the envelope. Spill failures never block the call (inline + warning). - `jsonShapeSkeleton` computes a bounded structural map (depth 4, arrays as `"array[N] of <type>"`, id-keyed maps collapsed, long leaves as size markers, hard-capped at 1024 bytes) so the model knows the key paths in one pass. - Optional per-tool `largeOutputHint` (on the `Tool` type, threaded via the descriptor) is used as the hint when present, else a generic hint. The `shape` is always computed generically. ## Surfaces Spilling is an opt-in flag (`spillLargeOutput`) mirroring `compactOutput`: | Surface | `spillLargeOutput` | Behavior | | --- | --- | --- | | AI chat / agent | `true` (in `chat-execution.service.ts`) | Spill on; nav tools + `code_interpreter` in catalog | | External MCP clients | unset | Raw output | | Workflow agents | unset | Raw output | | `code_interpreter` sandbox bridge | unset (it's an MCP call) | Raw output | The sandbox bridge inherits "no spill" for free via the MCP path — no header sniffing, no `ToolContext.source` field. ## Design constraints (anti-micro-OS) Exactly two navigation tools, no composition/piping, read-only, bounded output. The boundary is: expressible as a single path lookup or text search → nav tool; aggregation/correlation/transform → `code_interpreter`. ## Notes / deviations from the plan - `jsonShapeSkeleton` and `ToolOutputSpillService` live under the `tool` module (not `tool-provider/output-transforms`) to avoid a `tool → tool-provider` import cycle. - Spill files use `{ isTemporaryFile: false, toDelete: false }` (same as `code_interpreter`); `isTemporaryFile` here means files-field promotion, not a TTL. ## Test plan - [x] `extract-json-path` + `search-output` util unit tests (23 cases) - [x] `jsonShapeSkeleton` unit tests (6) and `ToolOutputSpillService` unit tests (4) - [x] oxlint + oxfmt clean on changed files; `twenty-server` typecheck clean (pre-existing unrelated errors aside) - [ ] Manual: trigger an oversized tool result in chat, confirm the envelope is returned and `extract_json_path` / `search_output` read the spilled file by `fileId` ## Why no automated e2e Spilling is chat-only and the chat path runs a live model, so the black-box MCP integration harness can't deterministically trigger a spill (MCP intentionally doesn't spill). The seam is small, explicit flag-threading mirrored on `compactOutput`, covered by the unit suites. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21982?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-23 10:46:06 +00:00
Charles Bochet	a884945aca	fix(deps): remediate HIGH image vulns (multer, ws, nodemailer) (#21984) ... ## What Clears the HIGH-severity AWS Inspector findings on the `twenty-server` container image. All three have stable, in-range fixes — no prereleases. | Package | From → To | CVE | Path | |---------|-----------|-----|------| | multer | 2.1.1 → **2.2.0** (resolution) | CVE-2026-5038, CVE-2026-5079 (DoS) | transitive via `@nestjs/platform-express` | | ws | 8.20.1 → **8.21.0** (resolution) | CVE-2026-48779 | pinned by `@nestjs/graphql` (8.21.0 already in tree) | | nodemailer | 8.0.10 → **9.0.1** | GHSA-p6gq-j5cr-w38f | nested in `imapflow`; bumped `imapflow` 1.3.6 → 1.4.2 which depends on nodemailer 9.0.1 | ## Notes - **multer 2.2.0 is the stable fix.** The advisories ([CVE-2026-5038](https://advisories.gitlab.com/npm/multer/CVE-2026-5038/), [CVE-2026-5079](https://advisories.gitlab.com/npm/multer/CVE-2026-5079/)) list both `2.2.0` and `3.0.0-alpha.2` as fixed; Inspector reported only the `3.0.0-alpha.2` prerelease, but we stay on the stable 2.x line. - **nodemailer:** the top-level dep was already `^9.0.1`; only `imapflow`'s nested copy was stale. imapflow 1.4.0 still ships nodemailer 8.0.10 and 1.4.1 ships 9.0.0 (< the 9.0.1 fix), so **1.4.2 is the minimum** that pulls the patched nodemailer. - Lockfile-only resolution for multer/ws (they're transitive); imapflow is a direct dep bump. yarn.lock net-shrinks from deduping. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21984?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-23 00:54:46 +02:00
Abdullah.	c171c62099	chore(twenty-server): upgrade typeorm to 0.3.29 (#21957) ... ## Summary Upgrades **typeorm `0.3.26` → `0.3.29`** and adapts the twenty-orm `update`/`upsert` overrides to typeorm's newly-added `options.returning`. Upgrading to resolve [this](https://github.com/twentyhq/twenty/security/dependabot/1573) alert. ## Why `0.3.29` is the latest release compatible with `@ptc-org/nestjs-query-typeorm` (peers `typeorm@^0.3.15`; the `1.x` line has no compatible release, so it's blocked until that dependency moves). ## Changes **`chore` — bump** - `typeorm` patch descriptor `0.3.26 → 0.3.29` + `yarn.lock`. - Local patch carried over **unchanged** (pure rename) — both hunks (`PickKeysByType` nullable-awareness, `DeleteResult.generatedMaps`) are still absent upstream in `0.3.29`, so it remains load-bearing. **`refactor` — adapt overrides** - `0.3.29` adds `options?: UpdateOptions` (carrying `returning`) to `EntityManager`/`Repository` `update()`. The override must accept it at the base-mandated position, so it's added as its **own dedicated parameter** (not hidden inside `permissionOptions`), honoring `options.returning` with a fallback to Twenty's permission-aware `selectedColumns` (`'*'` default). - The same merge is applied to `upsert()`, which already received `UpsertOptions` but was dropping its `returning` field — so both write methods now treat the option identically. - Internal call sites + specs updated for the new parameter slot. ## Verification - `nx typecheck twenty-server` — **0 errors** - twenty-orm unit tests — **191 / 191 pass** - `oxlint` / `oxfmt` — clean	2026-06-22 16:08:09 +02:00
Abdullah.	e90fb4b55c	fix(security): bump dompurify to 3.4.11 (config/hook pollution) (#21905) ... ## fix(security): bump dompurify to 3.4.11 (config/hook pollution) Resolves [Dependabot Alert #1520](https://github.com/twentyhq/twenty/security/dependabot/1520) and [#1509](https://github.com/twentyhq/twenty/security/dependabot/1509). ### What `dompurify` is affected by: - **Permanent `ALLOWED_ATTR` pollution via `setConfig()`** ([#1520](https://github.com/twentyhq/twenty/security/dependabot/1520), Moderate, `<= 3.4.10`) - **Trusted Types policy survives `clearConfig()`** ([#1509](https://github.com/twentyhq/twenty/security/dependabot/1509), Low, `< 3.4.9`) Both patched in `3.4.11`. Bumps the direct `twenty-server` dep `^3.4.0 -> ^3.4.11`. ### Compatibility Both advisories are about config/hook state pollution via `setConfig`/`clearConfig`/hooks. All four of our call sites use plain `DOMPurify(window).sanitize(...)` with **default config** — no `setConfig`, `clearConfig`, `addHook`, `ALLOWED_ATTR`, or `RETURN_TRUSTED_TYPE` — so we are not on the affected path, and the fix does not change default-`sanitize` behavior. Verification: `typecheck twenty-server` passes; the `prepare-file-for-storage`, `create-html-to-text-converter`, and `email-composer` suites pass (28 tests). ### Verification - `dompurify` resolves to `3.4.11` (no `<= 3.4.10` remains). - Lockfile + single package.json pin change; `yarn install --immutable` passes.	2026-06-21 15:05:17 +02:00
Abdullah.	d74b6aeadf	fix(security): bump nodemailer to 9.0.1 (raw-option SSRF / file read) (#21903) ... ## fix(security): bump nodemailer to 9.0.1 (raw-option SSRF / file read) Resolves [Dependabot Alert #1518](https://github.com/twentyhq/twenty/security/dependabot/1518) and [#1519](https://github.com/twentyhq/twenty/security/dependabot/1519). ### What `nodemailer` `<= 9.0.0` lets the message-level `raw` option bypass `disableFileAccess`/`disableUrlAccess`, enabling **arbitrary file read** and **full-response SSRF** in the delivered message ([GHSA advisory](https://github.com/twentyhq/twenty/security/dependabot/1518), High). Patched in `9.0.1`. ### How — direct bump, no resolution - **twenty-server:** `nodemailer ^8.0.5 -> ^9.0.1` (major bump). - **seed-dependencies:** the application-package template `nodemailer ^8.0.5 -> ^9.0.1`; both `DEFAULT_PACKAGE_JSON_CHECKSUM` and `DEFAULT_YARN_LOCK_CHECKSUM` regenerated to match the recomputed seed files (the deps-layer cache key). ### Compatibility — verified nothing breaks It is a major upgrade, so the 9.0 breaking change was checked against the current tree. The only behavior change is **stricter TLS validation when nodemailer fetches remote content** (attachment `href`/`path` URLs, built-in OAuth2 token endpoints, HTTP/HTTPS proxy `CONNECT`). None of those paths are reachable here: - Attachments are passed as **content buffers**, never `path`/`href`. - Gmail OAuth uses **googleapis**, not nodemailer's built-in OAuth2. - No proxy on any transport. - The SMTP socket TLS is governed separately (unchanged). Verification: `typecheck twenty-server` passes (with `@types/nodemailer ^7.0.3`), and the `email-sender`, `gmail-message-outbound`, and `imap-smtp-caldav-connection` suites pass (10 tests). ### Not covered (follow-up) Root alert **#1521** will stay open: `imapflow@1.3.6` exact-pins `nodemailer@8.0.10`. The clean fix is `imapflow 1.4.2` (which pins nodemailer `9.0.1`), but it published 2026-06-19 and is **age-gated until ~2026-06-22** — it will land then as a parent-bump (no resolution). ### Verification - `nodemailer` resolves to `9.0.1` for twenty-server; seed lockfile has `9.0.1`; both seed checksums match the canonical recompute. - `yarn install --immutable` passes.	2026-06-21 15:05:00 +02:00
Félix Malfait	bb6da7b7d1	feat(code-interpreter): reuse a warm sandbox per conversation (E2B) (#21664) ... ## What The E2B code-interpreter driver created a **fresh sandbox on every execution** and killed it in `finally`, so every call in a conversation paid full cold-start and started blank. This PR keeps **one warm sandbox per conversation** and, on idle, **pauses** it rather than killing it. ## How - **Discovery without a registry:** the sandbox is tagged with the chat `threadId` (scoped `workspaceId:threadId`) via E2B **metadata**, found with `Sandbox.list({ query: { state: ['running','paused'], metadata } })` and resumed with `Sandbox.connect()` (which auto-resumes a paused sandbox). E2B is the source of truth — no Redis/DB mapping. - **Pause/resume (E2B 2.x):** session sandboxes are created with `lifecycle: { onTimeout: 'pause', autoResume: true }`. When idle they **pause** — compute billing stops, filesystem **and** kernel/memory state are preserved — and resume in ~1s on the next call. This replaces the earlier keepalive approach. - **No premature pause mid-run:** the sandbox is kept alive for `max(execution timeout, idle window)`, so a long execution is never paused underneath itself. - **Tenant isolation:** discovery filters by the `twentySessionId` tag and **re-checks it client-side**, so a loose server-side match can never hand one conversation's warm sandbox (with its files, kernel state, token) to another. - **Concurrency:** executions sharing a session are serialized in-process (one active stream per thread, run as a single job — the chat resolver queues concurrent messages), so parallel tool calls can't race the shared kernel. - **Output isolation:** `/home/user/output` is reset at the start of each reused run, so a call only returns the artifacts it actually produced; durable state lives elsewhere and persists. ## SDK upgrade `@e2b/code-interpreter` **`^1.0.4` → `^2.6.0`** (pulls `e2b@2.x`). The typed pause/resume API, `lifecycle`, and the `state`/`metadata` list filter only exist in the 2.x line; 1.x exposed them only as untyped OpenAPI internals. `Sandbox.list()` is now a paginator (handled). ## Config | Var | Default | Purpose | |---|---|---| | `CODE_INTERPRETER_TIMEOUT_MS` | `300000` | Max single-execution duration. | | `CODE_INTERPRETER_IDLE_TIMEOUT_MS` | `300000` | Idle window before the warm sandbox auto-pauses. | Reuse is always-on when a session id is present (chat path). The workflow-agent path and the dev-only `LocalDriver` are unaffected. ## ⚠️ Open item before merge: paused-sandbox GC E2B retains paused sandboxes **indefinitely** (no TTL). Unlike the old keepalive path (which auto-killed on idle), pause means a conversation's sandbox persists after the chat ends — so without garbage collection, paused sandboxes accumulate (≈ one per historical conversation) and consume storage. A GC policy is required; the approach + retention window are being decided (see PR discussion). Also: the E2B runtime path can't run in CI, so this still needs a **live smoke test** (reuse hit, idle→pause, resume) and confirmation of paused-storage pricing before rollout. ## Tests / checks - Resolver unit tests (`getOrCreateSessionSandbox`): reuse+extend, create-when-absent, duplicate reaping, connect-failure fallback, keep-first-connectable-when-earlier-dead, **ignore cross-tenant metadata**, and **kill-on-timeout-refresh-failure**. - `nx typecheck twenty-server` (against e2b 2.x), `oxlint --type-aware`, `oxfmt --check` all clean. --------- Co-authored-by: Claude <noreply@anthropic.com>	2026-06-17 08:12:24 +00:00
dependabot[bot]	ebababcda1	chore(deps): bump @ai-sdk/amazon-bedrock from 4.0.97 to 4.0.117 (#21569) ... Bumps [@ai-sdk/amazon-bedrock](https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock) from 4.0.97 to 4.0.117. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/vercel/ai/blob/@ai-sdk/amazon-bedrock@4.0.117/packages/amazon-bedrock/CHANGELOG.md">@​ai-sdk/amazon-bedrock's changelog</a>.</em></p> <blockquote> <h2>4.0.117</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies [bfa5864]</li> <li>Updated dependencies [f42aa79] <ul> <li><code>@​ai-sdk/provider-utils</code><a href="https://github.com/4"><code>@​4</code></a>.0.29</li> <li><code>@​ai-sdk/anthropic</code><a href="https://github.com/3"><code>@​3</code></a>.0.84</li> <li><code>@​ai-sdk/openai</code><a href="https://github.com/3"><code>@​3</code></a>.0.71</li> </ul> </li> </ul> <h2>4.0.116</h2> <h3>Patch Changes</h3> <ul> <li>f0b5c16: fix(provider/amazon-bedrock): detect Cohere embedding models behind cross-region inference profile ids</li> <li>Updated dependencies [942f2f8] <ul> <li><code>@​ai-sdk/provider-utils</code><a href="https://github.com/4"><code>@​4</code></a>.0.28</li> <li><code>@​ai-sdk/anthropic</code><a href="https://github.com/3"><code>@​3</code></a>.0.83</li> <li><code>@​ai-sdk/openai</code><a href="https://github.com/3"><code>@​3</code></a>.0.70</li> </ul> </li> </ul> <h2>4.0.115</h2> <h3>Patch Changes</h3> <ul> <li>c97ede5: fix(provider/amazon-bedrock): extract Cohere embedding token usage from response header</li> </ul> <h2>4.0.114</h2> <h3>Patch Changes</h3> <ul> <li>2a91a17: feat(provider/anthropic): add support for <code>claude-fable-5</code> and the <code>fallbacks</code> API parameter</li> <li>Updated dependencies [9a55f6d]</li> <li>Updated dependencies [2a91a17] <ul> <li><code>@​ai-sdk/openai</code><a href="https://github.com/3"><code>@​3</code></a>.0.69</li> <li><code>@​ai-sdk/anthropic</code><a href="https://github.com/3"><code>@​3</code></a>.0.82</li> </ul> </li> </ul> <h2>4.0.113</h2> <h3>Patch Changes</h3> <ul> <li>Updated dependencies [c65c952] <ul> <li><code>@​ai-sdk/openai</code><a href="https://github.com/3"><code>@​3</code></a>.0.68</li> </ul> </li> </ul> <h2>4.0.112</h2> <h3>Patch Changes</h3> <ul> <li>53b002d: added bedrock mantle provider</li> </ul> <h2>4.0.111</h2> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/vercel/ai/commit/bae9babb22e195e74a9a0c0e26a5e52c8ba8e7f2"><code>bae9bab</code></a> Version Packages (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/16026">#16026</a>)</li> <li><a href="https://github.com/vercel/ai/commit/9ef2c3cfadfc4a469e9eec6a6e8a0ac0fc80a1e5"><code>9ef2c3c</code></a> Version Packages (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/15998">#15998</a>)</li> <li><a href="https://github.com/vercel/ai/commit/f0b5c16ce5f17a7c9cc91ce0ae8f292920594e91"><code>f0b5c16</code></a> Backport: fix(provider/amazon-bedrock): detect Cohere embedding models behind...</li> <li><a href="https://github.com/vercel/ai/commit/dca8c38b09acba1a5eebf354b532833ab055413a"><code>dca8c38</code></a> Version Packages (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/15992">#15992</a>)</li> <li><a href="https://github.com/vercel/ai/commit/c97ede5cbbbc0aaca0137ed41c7fd6f5fedd23b6"><code>c97ede5</code></a> Backport: fix(provider/amazon-bedrock): extract Cohere embedding token usage ...</li> <li><a href="https://github.com/vercel/ai/commit/f6e588173713842794c619f9554a4b341c6e97f5"><code>f6e5881</code></a> Version Packages (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/15902">#15902</a>)</li> <li><a href="https://github.com/vercel/ai/commit/2a91a17e0b885968814110fe3581d1ea0fd589ae"><code>2a91a17</code></a> backport: feat(provider/anthropic): add support for <code>claude-fable-5</code> and the ...</li> <li><a href="https://github.com/vercel/ai/commit/de852ab79aac88345c8a9ae54003fb206e1a64b4"><code>de852ab</code></a> Version Packages (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/15821">#15821</a>)</li> <li><a href="https://github.com/vercel/ai/commit/879395199bac3796e6c34b43f6aa43ca5d682940"><code>8793951</code></a> Version Packages (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/15755">#15755</a>)</li> <li><a href="https://github.com/vercel/ai/commit/53b002d2d0701235026b41e0fa11aa1a41c90b8b"><code>53b002d</code></a> Backport: feat (provider/amazon-bedrock): add bedrock mantle provider (<a href="https://github.com/vercel/ai/tree/HEAD/packages/amazon-bedrock/issues/14246">#14246</a>...</li> <li>Additional commits viewable in <a href="https://github.com/vercel/ai/commits/@ai-sdk/amazon-bedrock@4.0.117/packages/amazon-bedrock">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21569?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-06-15 10:24:09 +02:00
Charles Bochet	fb4608e437	chore(deps): upgrade Tier-1 deps (googleapis 173, gaxios 7, express 5, jsdom 29, date-fns 4, stripe 20) (#21570) ... ## What Security-driven upgrade of the biggest-drift Tier-1 dependencies (staying on latest = staying patched). Bundled because they share the lockfile and the googleapis/gaxios pair must move together. | Package | From | To | Gap | |---|---|---|---| | googleapis | 105.0.0 | **173.0.0** | 68 majors | | gaxios | 5.1.3 | **7.1.5** | 2 majors | | express | 4.22.2 | **5.2.1** | 1 major | | jsdom | 26.1.0 | **29.1.1** | 3 majors | | date-fns | 2.30.0 | **4.4.0** | 2 majors | | date-fns-tz | 2.0.0 | **3.2.0** | 1 major | | stripe | 19.3.1 | **20.4.1** | 1 major | `yarn npm audit` reports **0 high/critical** advisories before and after. ## Code changes - **gaxios v7** — `GaxiosError.code` is now `string | number` (guard the calendar network-error check by `typeof`); `GaxiosError` config/response use `URL` + `Headers`; and crucially the v7 constructor drops `response.data` unless `bodyUsed` is set — updated the synthetic gmail error mocks accordingly (production gaxios sets it, so real error parsing is unaffected). - **google-auth-library / gaxios dedup** — `googleapis-common@8.0.2` exact-pins `google-auth-library@10.5.0` + `gaxios@7.1.3` while `googleapis` pulls `^10.2.0`; the two copies made `OAuth2Client`/`GaxiosError` type-identities diverge across every gmail/calendar service. Added two singleton `resolutions` (documented inline in root `package.json`). - **express 5** — no source changes. `@nestjs/platform-express@11.1.24` already resolves `express@5.2.1` internally; the old `4.22.2` pin was the override. - **jsdom 29** — no source changes, but it now pulls ESM-only transitive deps (`@csstools/*` `.mjs`, `parse5`, `entities`, `tough-cookie`, `@exodus/bytes`). Extended the server jest `transformIgnorePatterns` allowlist and added `.mjs` to the transform/extensions so jest can load jsdom. - **stripe 20** — `Subscription` gained a required `customer_account` field; added to mocks. No runtime changes. - **date-fns v4** — `Locale` is no longer ambient (import explicitly in 5 files); per-locale entrypoints dropped the typed `default` export (the locale loader now reads the single named export); fixed the default locale import in `formatTimeZoneLabel`. ## Tests - Full suites green locally: **twenty-server 5709 passed**, **twenty-front 4937 passed**, twenty-ui / twenty-ui-deprecated green; typecheck + builds (swc + vite) + lint all pass. - Added regression tests for the two runtime behaviors these upgrades touch and that had no coverage: - `getDateFnsLocale` — named-export locale resolution (date-fns v4). - `sanitizeFile` — jsdom 29 + DOMPurify still strips `<script>`/event handlers from uploaded SVGs (security guard). ## Deliberately deferred (not in this PR) - **stripe → 21/22**: stripe **21** bundles a runtime `Decimal` type for money fields **and** jumps the pinned API version to `2026-03-25.dahlia` (changes webhook/billing payload behavior) — too risky to fold into a deps bump on billing code. stripe **22** additionally drops the node10-resolvable `types` entry, which would force a repo-wide `moduleResolution` change. Capped at the latest clean **20.x**. - **openid-client → 6**: v6 is a full functional rewrite and its passport strategy manages the OAuth `state` internally, but our SSO flow uses `state` to carry `identityProviderId` across the shared `/auth/oidc/callback`. That needs an auth-flow redesign (session-carried provider id) on Enterprise SSO code with no integration harness — it deserves its own focused PR rather than riding along here. ## Tier-1 source Originated from a dependency-drift audit; remaining Tier-1 items (date-fns done here) plus Tier-2/3 follow-ups tracked separately. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21570?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-15 10:23:42 +02:00
Charles Bochet	7c0136b97b	feat(deps): migrate frontend to React 19 (#21531) ... ## What Migrates the frontend stack from **React 18.3 → 19.2**. The website, sdk, companion and emails packages were already on React 19; this brings the remaining holdouts (`twenty-front`, `twenty-ui`, `twenty-ui-deprecated`, `twenty-front-component-renderer`) and `twenty-server`'s email rendering onto 19, and pins a single React version repo-wide. ## Why React 18.x is now the legacy line. Staying current keeps us on the patched/maintained branch and unblocks downstream library majors (react-router 7, mantine 9, etc.) that require React 19 peers. ## Dependency bumps (required by React 19 peers / removed APIs) | Package | From | To | Reason | |---|---|---|---| | react / react-dom | 18.3.1 | 19.2.3 | core | | @hello-pangea/dnd | 16 | 18 | peer `^18 \|\| ^19` | | react-datepicker | 6 | 9 | v<7 used removed `findDOMNode`; drops `@types/react-datepicker` | | react-data-grid | beta.13 | beta.59 | peer `^19.2`; new render API | | graphiql (+ @graphiql/react, plugin-explorer) | 3 / 0.23 / 1 | 5 / 0.37 / 5.1 | peer `^18 \|\| ^19` | | react-helmet-async | 1.3 | **@dr.pogodin/react-helmet** 3.2 | upstream caps peer at `^18`; drop-in React 19 fork | A `resolutions` pin enforces a single React (19.2.3) + `@types/react` (19.2.14) across the monorepo to avoid duplicate copies / type-identity splits. Versions are the aged lockfile patches (clears the `npmMinimalAgeGate`). ## Code changes - **Global `JSX` shim** (`react-jsx-global.d.ts` per package): React 19 moved the `JSX` namespace under `React.JSX`; several deps' published types (notably `@linaria/react`'s `styled.d.ts`, which types every `styled.x` via `keyof JSX.IntrinsicElements`) still reference the global namespace. Without the shim, every styled component degrades to `any` props. - **Ref nullability**: `useRef<T>(null)` now returns `RefObject<T | null>`; widened consumer prop/hook ref types accordingly (incl. the shared `useListenClickOutside`). - **react-datepicker v9**: `onChange`/`onSelect` accept `Date | null`, `calendarStartDay` typing, `ReactDatePickerProps`→`DatePickerProps`, relaxed the dynamic `selectsMultiple` discriminated union. - **react-data-grid beta.59**: `formatter`→`renderCell`, `editor`→`renderEditCell`, `headerRenderer`→`renderHeaderCell`, `components`→`renderers`, `onRowClick`→`onCellClick`, object-shaped `useRowSelection`, Set-based selection. - **dnd style cast**: `@radix-ui/react-popper` augments `CSSProperties` with a `--radix-*` index signature that dnd's closed `DraggingStyle` doesn't satisfy → cast at the spread. ## Status / testing - ✅ `typecheck` green: twenty-front, twenty-ui, twenty-ui-deprecated, twenty-front-component-renderer, twenty-server - ⏳ build / lint / unit tests / storybook+argos / runtime smoke-test in progress Draft until local + CI verification completes. Notable behavior to QA manually: spreadsheet import (data-grid), date pickers, drag-and-drop boards/lists, GraphQL playground, page titles/favicon. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/twentyhq/twenty/pull/21531?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. -->	2026-06-14 15:42:22 +02:00
Charles Bochet	503c689f37	security: upgrade typeorm to 0.3.26 (CVE-2025-60542) (#21456) ... ## Context Retry of the typeorm upgrade that was pulled out of #21448 after CI showed "intermittently lossy metadata sync". **The investigation exonerated typeorm**: the postcard/seed failures were a pre-existing bug in `@ptc-org/nestjs-query-typeorm`'s batched relation paging (global LIMIT across parents) that scan-order luck had been hiding — reproduced byte-for-byte on typeorm **0.3.20** against a frozen repro DB. That bug is fixed in #21455, which this PR is stacked on (base branch = `charles/fix-nestjs-query-batch-relation-paging`; will retarget to main when it merges). ## Changes - typeorm `0.3.20` → `0.3.26` ([CVE-2025-60542](https://github.com/advisories/GHSA-q2pj-6v73-8rgj), MEDIUM). The CVE lives in TypeORM's MySQL path (`sqlstring`/`stringifyObjects`); Postgres-only Twenty never exercises it — this is scanner hygiene + staying current. - The local yarn patch (`PickKeysByType` + `DeleteResult.generatedMaps`) applies **verbatim** to 0.3.26 (verified against the pristine tarball) — renamed to `typeorm+0.3.26.patch`. - `WorkspaceRepository.query` restricted override adapted to the generic `query<T = any>()` base signature introduced in 0.3.24 (one-line change, still throws `RAW_SQL_NOT_ALLOWED`). - 0.3.26 ships `uuid ^11` natively → the scoped `typeorm/uuid` resolution from #21441 and its `//resolutions` comment clause (including the now-disproven "lossy sync" warning) are removed. ## Why we're confident this time The original failure signature was fully understood, not just retried: - On a frozen failing DB, **all fieldMetadata rows + workspace columns were intact** — only the batched metadata API read was truncated (`LIMIT 501` over 558 rows, no ORDER BY). - Same DB, typeorm 0.3.20: identical truncation, identical SQL → not a typeorm regression. - With #21455 applied: postcard install/uninstall stress loop **12/12 green on typeorm 0.3.26** (previously failed within 1–2 iterations), API returns 558/558 fields. ## Verification - `npx nx typecheck twenty-server` — clean - Full `twenty-server` unit suite — green (5651 passed) - `group-by-resolver` integration suite — 19/19 on a fresh 0.3.26-seeded test DB - Postcard app-sync stress loop — 12/12 on this exact stack - Lockfile: typeorm 0.3.26 + new `sql-highlight` dep, `esbuild`/uuid entries untouched	2026-06-11 16:41:22 +02:00
Charles Bochet	d75685b8dc	fix(metadata): nestjs-query batched relation queries truncate results across parents (#21455) ... ## TL;DR The metadata API silently drops relation rows whenever a batched relation query exceeds the requested page size. A dev-seeded workspace already has **558 fieldMetadata rows across 31 objects**, so `objects(paging:{first:50}) { fields(paging:{first:500}) }` executes: ```sql SELECT DISTINCT ... FROM core."fieldMetadata" fields WHERE workspaceId = $1 AND objectMetadataId IN (...31 ids...) LIMIT 501 OFFSET 0 -- no ORDER BY ``` …and returns exactly **501 of 558** fields — ~57 rows dropped, and *which object loses which field is scan-order-dependent*. This is what made `example-app-postcard` CI flap with "PostCard object missing field X" (different X per run). ## Root cause `@ptc-org/nestjs-query-typeorm`'s `batchQueryRelations` (the DataLoader batch path behind every `@CursorConnection`) applies the **per-parent** page size as a **single global LIMIT** on the batched query, then groups rows per parent in memory. Any batch whose combined relation rows exceed `first + 1` truncates arbitrary parents. This affects production metadata reads, not just CI — any workspace with enough fields/objects loses rows in `objects.fields`-style connections. ## Fix Yarn patch on `@ptc-org/nestjs-query-typeorm@9.4.0` (same vehicle as the existing `nestjs-query-graphql` patch): - `RelationQueryBuilder.batchSelect`: only apply LIMIT/OFFSET when the batch has a **single parent**; multi-parent batches stay **bounded** with `parents × (offset + limit)` — the upper bound a correct per-parent pager can ever need, so it cannot wrongly truncate while still guarding against unbounded fetches on high-cardinality relations; - `batchQueryRelations`: enforce paging **per parent** by slicing after `mapRelations` (preserves the `first + 1` hasNextPage probe semantics). ## Verification - On a frozen repro DB (postcard installed, 558 fields): unpatched returns 501 fields with `postCard` missing `deliveredAt`; patched returns **558/558** with the full `postCard` field set. Reproduced identically on typeorm 0.3.20 and 0.3.26 — pre-existing bug, **not** a typeorm regression (this unblocks the typeorm upgrade that was reverted from #21448). - Postcard install/uninstall stress loop: unpatched fails within 1–2 iterations; patched **12/12 green**. - `npx nx typecheck twenty-server` clean, full `twenty-server` unit suite green (5651 passed). ## Related #21435 chases the **same CI symptom** (postcard randomly missing a freshly synced field) at a different layer — a workspace-cache write racing invalidation. The two are complementary: the repro behind this PR survives a **cold server restart + `redis-cli FLUSHALL`** with all rows intact in Postgres, which no cache race can explain — the truncation happens on the DB read itself (`LIMIT 501` over 558 matching rows, captured via `log_statement=all`). Both fixes are likely needed for the postcard job to be fully reliable. ## Notes Worth upstreaming to `@ptc-org/nestjs-query` eventually; the proper upstream fix is per-parent windowed pagination (`ROW_NUMBER() OVER (PARTITION BY parentId)`), but the in-memory per-parent slice is correct and proportionate at metadata-API scale.	2026-06-11 16:39:14 +02:00
Charles Bochet	184c4948d6	security: strip Node dev headers from images + lingui 5.9.5 (drops vulnerable esbuild) (#21448) ... ## Context AWS Inspector flags the `prod-twenty` image (built from current main) with 16 findings, and Dependabot alert 174 flags esbuild. This PR fixes the OpenSSL scanner findings and the esbuild CVE. The typeorm bump (CVE-2025-60542) was **pulled out of this PR** — see "typeorm status" below. ## Changes ### Strip `/usr/local/include/node` from runtime stages (`twenty-server`, `twenty-app-dev`) 15 OpenSSL CVEs (June 9 advisory, incl. CRITICAL CVE-2026-34182) are all detected via **Node's bundled OpenSSL dev headers**: 3 GENERIC `openssl/openssl` 3.5.6 detections per CVE at `/usr/local/include/node/openssl/archs/linux-x86_64/{asm,asm_avx2,no-asm}/include/openssl/opensslv.h`. The headers are only needed by node-gyp and native addons are compiled in the build stages — nothing compiles at runtime. Dropping them clears all 45 detection instances and permanently ends this class of finding (third occurrence: 3.5.5 → 3.5.6 → 3.5.7). None of these CVEs are reachable through Node (no CMS/PKCS#7 API, `pfx` is operator-supplied, Node's QUIC uses ngtcp2, ASN.1 issues need ~2GB inputs). **Follow-up (~June 17, 2026):** the `node` binary itself still statically links OpenSSL 3.5.6 — invisible to the scanner after this PR and unreachable in practice, but the real fix is bumping the pinned `node:24-alpine` digest once the [announced June 17 Node.js security releases](https://nodejs.org/en/blog/vulnerability/june-2026-security-releases) ship a 24.x linking OpenSSL ≥ 3.5.7 (verify via `deps/openssl/openssl/VERSION.dat` on the release tag — 24.16.0 is still on 3.5.6). A dated TODO sits next to the cleanup in the Dockerfile. ### esbuild dev-server CORS CVE (Dependabot alert 174, GHSA-67mh-4wv8-2f99) `@lingui/cli@5.1.2` (pins `esbuild ^0.21.5`) was the last parent resolving a vulnerable esbuild (≤ 0.24.2 lets any website send requests to the dev server and read responses). Instead of a resolution override, this bumps the lockstepped **lingui suite 5.1.2 → 5.9.5** (within-major; lingui adopted `esbuild ^0.25.1` in 5.4.1), which: - removes `esbuild@0.21.5` and all its platform packages from the lockfile with no forced ranges; - drops the `@lingui/core` lockstep resolution (its comment marked it droppable on the next coordinated lingui bump — the tree now resolves a single `@lingui/core@5.9.5`); - `@lingui/swc-plugin` stays at `^5.11.0` (peers on `@lingui/core: 5`; its 6.x line targets lingui 6). **lingui 5.9.5 behavioral fallout handled here:** - Translation functions now **throw without an active locale** (5.1.2 fell back silently). The global `i18n` singleton that backs server-side `` t`…` `` calls only had a messages compiler set, never an activated locale → activate the source locale in `I18nService.loadTranslations()`, mirrored in the server jest setup (unit tests bypass Nest bootstrap). - `msg`/`t` placeholders are now strictly typed (reject `null`/`undefined`/`unknown`) → one server call site and 16 twenty-front files adapted with minimal nullish-coalescing fixes that preserve rendering. - `.po`/compiled-catalog churn from the new extractor/compiler (reference reordering, sorted keys — verified content-identical on unchanged `.po` inputs) is intentionally not committed: the scheduled i18n workflows regenerate those. ## typeorm status (pulled out) typeorm 0.3.20 → 0.3.26 was originally in this PR but **made workspace metadata sync intermittently lossy**: `example-app-postcard` failed twice with a *different* field missing from the synced PostCard object each run, and one integration shard's `DataSeedWorkspaceCommand` died with "Could not find flat entity with universal identifier …" — versus zero such failures on recent main. Local runs (db reset + seed, group-by integration suite 19/19) pass, so it is a nondeterministic CI-load-sensitive regression that needs dedicated debugging (typeorm changed LIMIT/OFFSET 0 semantics, lazy count for `getManyAndCount`, upsert WHERE construction, and topological-sort internals in that range). The resolutions comment documents this as the blocker; CVE-2025-60542 is MySQL-driver-only (`sqlstring`), so Postgres-only Twenty is not exposed in the meantime. ## Verification - `npx nx typecheck twenty-server` / `twenty-front` — clean (no cache) - `npx nx test twenty-server` — full suite green - `lingui:extract` + `lingui:compile` — clean for twenty-server / twenty-emails / twenty-front - `oxfmt --check` — clean for both packages - Lockfile diff: lingui 5.9.5 entries, `esbuild@0.21.5` + `@esbuild/*@0.21.5` platform packages removed, no typeorm changes	2026-06-11 15:11:29 +02:00
Charles Bochet	166f7ee0d2	chore(deps): prune yarn resolutions down to load-bearing entries (#21446) ... ## Context Audit of all 28 `resolutions` entries in the root package.json against yarn.lock dependency graphs and the npm registry, to remove every entry that is no longer forcing anything a normal resolution wouldn't do — resolutions are hard to maintain and silently freeze versions. Net result: **28 → 22 entries**, two small dependency bumps replace pins, and every remaining entry now has its blocker + removal condition documented in `//resolutions`. ## Removed — dead weight (re-resolution lands on the same safe versions) | Entry | Why it was dead | |---|---| | `type-fest: 4.10.1` | Stale 2024 dedup pin that semver-overrode ~16 of 19 declared ranges (forced `^0.13`/`^0.20`/`^0.21` consumers up four majors, `^5.x` consumers down one). Types-only; each parent now resolves its own compatible copy. | | `typescript: 5.9.3` | No-op: every range (`^5.9.3`, `5.9.3`, `~5.9.2`) resolves to 5.9.3 naturally. Only the electron-forge scaffolding template regains its own nested `~5.4.5` (never builds this repo). | | `node-gyp: ^12.4.0` | All requesters are Yarn-injected `node-gyp: latest` = 12.4.0 today. The tar-6-era node-gyp versions it evicted have no requesting parent left. | | `cacache: ^20.0.0` | All four parents (arborist, metavuln-calculator, make-fetch-happen 15, pacote 21) already declare `^20`. Guarded by the kept `make-fetch-happen: ^15` resolution. | | `pacote/tar: ^7.5.16` | The original target (pacote 11/15 via zapier) is gone; the only pacote left is 21.5.0 which declares `tar ^7.4.3` natively. | ## Removed — replaced by a parent upgrade - **`nodemailer: 8.0.10`** → `imapflow` 1.2.1 → **1.3.6** (ships patched nodemailer 8.0.10 exact; 1.4.0 is blocked by the 3-day npm age gate). twenty-server's own `^8.0.5` range was already safe. - **`node-ical/uuid: 11.1.1`** → `node-ical` ^0.20.1 → **^0.21.0**, which drops uuid (and axios) entirely. The uuid removal happened at 0.21.0 — not in the 0.26 rrule-temporal type overhaul that #21441 flagged as the blocker. ## Narrowed — `qs: 6.15.2` global → two scoped entries Only three lockfile entries actually request vulnerable qs ranges: `express@4.22.0` (pinned by `@mintlify/previewing`), `express@4.22.1` + `@cypress/request@3.0.10` (pinned by verdaccio 6.7.2, latest). Replaced the global pin with `express/qs` + `@cypress/request/qs`, so the 12+ healthy parents (express 4.22.2/5.x, body-parser, stripe, …) are no longer frozen and will pick up future qs releases naturally. ## Re-pinned — `graphql-redis-subscriptions/ioredis` Changed `^5.6.0` → exact `5.10.1` and documented why: this must equal the exact ioredis version pinned by twenty-server and bullmq. Without it, graphql-redis-subscriptions' `^5.3.2` resolves to a second ioredis copy and `RedisPubSub`'s publisher/subscriber types reject the server's client (caught by twenty-server typecheck during this work — bump it in lockstep with the ioredis pin). ## Kept (all load-bearing, now documented inline) graphql (singleton below msw's `^16.12.0`), @lingui/core (suite lockstep), @types/qs (6.9.17 typing-break holdback), @opentelemetry/api (NoopMeterProvider singleton, #20231), chokidar v3 (NestJS CLI fsevents, #20316), tmp (zapier-platform-cli pins 0.2.5), make-fetch-happen + the two @electron tar entries (blocked on electron-forge adopting @electron/rebuild 4), @angular-devkit/core (blocked on a fixed @nestjs/cli > 11.0.23), yeoman-environment, webpack-dev-server, next/postcss (fix only in next 16.3.0 canaries), the remaining uuid pins, and react-doc-viewer/ajv. ## Follow-ups (separate PRs) - `typeorm` 0.3.20 → 0.3.30: re-roll the 46-line patch; clears the `typeorm/uuid` resolution **and** the open high-severity GHSA-q2pj-6v73-8rgj (SQL injection in `repository.save/update`, fixed in 0.3.26). - googleapis 105 → ≥152 migration clears `googleapis-common/uuid`. ## Verification - `yarn install` clean; lockfile contains **no** vulnerable qs (≤6.15.1)/tar 6/uuid <11/nodemailer <8.0.4/postcss 8.4.31/tmp <0.2.6 entries - `npx nx typecheck twenty-server` ✓ and `npx nx typecheck twenty-front` ✓ - CalDAV + IMAP unit tests (node-ical/imapflow consumers): 9 suites, 121 tests ✓ - `yarn npm audit --all`: only pre-existing typeorm finding remains (see follow-up)	2026-06-11 13:41:03 +02:00
Charles Bochet	462dd3b0e9	security: uuid CVE — bump bullmq/msal/blocknote + scoped resolutions for the rest (Dependabot alert 1289) (#21441) ... Closes the uuid Dependabot alert — [1289](https://github.com/twentyhq/twenty/security/dependabot/1289) — by **upgrading the parents that bump cleanly** and **scope-resolving only the ones that genuinely can't**. `uuid < 11.1.1` (buffer-bounds check in v3/v5/v6) is pulled by ~9 transitives. ### Bumped (parent upgrade — drops uuid<11, no behavior change; typecheck verified) - **bullmq** 5.40.0 → 5.78.0 — also aligned **ioredis** 5.6.0 → 5.10.1 (bullmq pins it) and fixed the renamed `Job.returnValue→returnvalue` / `stackTrace→stacktrace` (now `string[]|null`) in `admin-panel-queue.service.ts`. - **@azure/msal-node** ^3.8.4 → ^5.2.3 (5.2.4 was age-gate-quarantined). - **@blocknote/** ×5 ^0.47.3 → ^0.51.4. ### Scope-resolved to uuid 11.1.1 (no clean bump exists) - **sockjs** (latest; pinned by webpack-dev-server) and **@ptc-org/nestjs-query-typeorm** (9.4.0 *is* latest, pins `^10`) — no version drops uuid. - **typeorm** — a `patch:` dep / ORM core, too risky to bump. - **node-ical** 0.26 (type-model overhaul → caldav-parser rewrite) and **googleapis** 173 (Gmail/OAuth, 105→173) — large breaking migrations; **deferred to dedicated PRs**. - **@cypress/request** — transitive (cypress isn't a direct dep). Resolutions are **per-package** and preserve the intentional **uuid 13.x** (twenty-sdk / create-twenty-app). ### Verification - `twenty-server` typecheck ✓ (0 errors), `twenty-front` typecheck ✓ (0 errors). - `yarn install --immutable` ✓; every uuid resolves to **11.1.1** or **13.0.2**. - bullmq/msal/typeorm runtime exercised by the **server integration tests**; @blocknote by the **storybook tests** in CI.	2026-06-11 12:26:26 +02:00
Charles Bochet	2da28cb03e	security: upgrade express 4.22.2 + qs 6.15.2 resolution for dev-tool holdouts (Dependabot alert 1305) (#21434) ... Closes the qs Dependabot alert — [1305](https://github.com/twentyhq/twenty/security/dependabot/1305) — by **upgrading express where possible** and using a **documented qs resolution** only for the irreducible dev-only holdouts. ### What's vulnerable `qs 6.14.x` (the `qs.stringify` DoS) is pulled by `express 4.22.1` / `body-parser 1.x`. The fix is `qs 6.15.2`, and there's **no backport to the 6.14 line**. ### Upgrade what we can (no resolution) `express 4.22.2` / `body-parser 1.20.5` moved to the patched `qs ~6.15.1`. So this PR bumps the app + in-range tooling to **express 4.22.2**: - twenty-server's stale direct pin `4.22.1 → 4.22.2` (its runtime HTTP is already express 5.2.1 via `@nestjs/platform-express`; this just patches the redundant direct dep — typecheck passes), - nx / electron-forge / webpack-dev-server / companion follow via `yarn up -R express body-parser`. ### Resolution only for the two holdouts Two **dev-only** tools pin express *exactly* with no patched release on a line we can use, so they still drag in `qs 6.14.2`: - **verdaccio** `4.22.1` — express 5 only landed in the **v7 beta** ([verdaccio#5680](https://github.com/verdaccio/verdaccio/issues/5680), [#2479](https://github.com/verdaccio/verdaccio/issues/2479)), **not** backported to the 6.x line we use. - **@mintlify/previewing** `4.22.0` — closed-source, latest still pins 4.22.0, no movement. A `qs: 6.15.2` resolution covers those, documented with a top-level `//resolutions` note and a removal trigger. ### Verification - `yarn install --immutable` ✓; every `qs` resolves to `6.15.2`; express app/tooling on `4.22.2` (only verdaccio/mintlify remain on old express, neutralized by the resolution). - `twenty-server` typecheck ✓ (90 files import express types; 4.22.1→4.22.2 is a patch). - Non-exploitable in prod regardless (express/body-parser use `qs.parse`, not the vulnerable `stringify`).	2026-06-11 10:46:04 +02:00
Charles Bochet	615c3d8dbe	security: drop end-of-life apollo-server-core (#735, #736) (#21418) ... Closes the `apollo-server-core` alerts (**#735**, **#736**) by **removing the dependency** — no Apollo migration, no resolution. ### Why these were flagged "no patch available" `apollo-server-core` is **Apollo Server v3, which is end-of-life** (per its npm deprecation notice). No patched release of this package will ever exist — the CVE fix lives only in the renamed `@apollo/server` v4 package. ### Why we can just drop it twenty-server **doesn't use Apollo Server** — its GraphQL runtime is **GraphQL Yoga** (`YogaDriver`). `apollo-server-core` was imported for one thing only: the `gql` template tag in **6 integration test files**. `gql` from `graphql-tag` is identical (apollo-server-core merely re-exports it), `graphql-tag` is **already a direct dependency**, and **15 other twenty-server tests already import `gql` from it**. ### Change - Swapped `import { gql } from 'apollo-server-core'` → `import { gql } from 'graphql-tag'` in the 6 test files. - Removed `apollo-server-core` from `packages/twenty-server/package.json`. - Result: `apollo-server-core` (and its transitive surface) is gone from `yarn.lock` entirely. ### Verification - `yarn install --immutable` ✓ - No `apollo-server-core` references remain in source or lockfile - Integration tests (which exercise the swapped `gql` imports) run in CI	2026-06-10 19:08:07 +02:00
Charles Bochet	1b26061992	security: close ws & file-type alerts via parent upgrades (no resolution) (#21417) ... Closes 3 more Dependabot alerts via **parent upgrades only — no `resolutions`**. ### Closes - **ws #1238** (`>= 8.0.0, < 8.20.1`) - **file-type #622** (`>= 13.0.0, < 21.3.1`) and **#635** (`>= 20.0.0, <= 21.3.1`) ### How - **ws** — two parents pinned vulnerable copies; both have safe releases: - `wrangler`/`miniflare`: `ws 8.18.0 → 8.20.1` - `socket.io`/`engine.io`/`socket.io-adapter`: `ws ~8.17.1 → ~8.20.1` - Every `ws` now resolves `>= 8.20.1` (or non-vulnerable 6.x/7.x). - **file-type** — bumped `@swc/cli ^0.7.10 → ^0.8.1`, which pulls the newer `@xhmikosr` bin-wrapper → downloader → decompress/archive-type chain (`file-type ^20.5.0 → ^21.3.x`). `@swc/cli` is a devDependency that isn't directly invoked (nx's swc compiler uses `@swc/core`), so this is dev-tooling-only with no runtime impact. ### Verification - `yarn install --immutable` ✓ (passes the hardened 3-day age gate) - No vulnerable `ws` (`< 8.20.1`) or `file-type` (`20.x`) remains in `yarn.lock` ### Remaining open alerts (not closeable without a `resolution` or a major migration) - `apollo-server-core` (#735/#736) — needs Apollo Server 3 → 4 - `webpack-dev-server` (#1237/#691/#692) — `@electron-forge/plugin-webpack` only pins `^4` (no stable v5 consumer); dev-tooling - `qs` (#1305) — `express`/`body-parser` pin `~6.14`, which has no patched release - `uuid` (#1289) — spread across many `^8`/`^9`/`^10` transitives; v11 is a breaking jump - `postcss` (#1061) — bundled exact by `next` and `styled-components` - `ajv` (#481) — `@cyntler/react-doc-viewer` pins `^7` (latest still does)	2026-06-10 19:03:28 +02:00
Charles Bochet	7258722754	security: upgrade @nestjs/graphql 12→13 + @ptc-org/nestjs-query 4→9 (+ @nestjs/config 4) (#21402) ... ## What Upgrades the NestJS GraphQL stack to clear the High **`ws`** alert (GHSA-3h5v-q93c-6h6q) and modernize off two heavily-patched majors. `@nestjs/graphql@13` pulls `ws@8.20.1` (was 8.16.0). This had to be a **coordinated** upgrade: `@ptc-org/nestjs-query@4.2.0` doesn't support `@nestjs/graphql@13`, so all three move together. | Package | From → To | |---|---| | `@nestjs/config` | 3.3.0 → ^4.0.4 | | `@nestjs/graphql` | 12.1.1 → ^13.4.2 | | `@ptc-org/nestjs-query-{core,graphql,typeorm}` | 4.x → ^9.4.0 | ## The tricky bits - **Re-ported the custom `@nestjs/graphql` patch onto v13.** v13 rewrote the schema builder and added its *own* native multi-schema support (`includeModules`, native `clear()`). Twenty's patch (`resolverSchemaScope` + `computeReachableTypes` — the core/metadata/admin split) is re-merged into v13's new `generate(options, includeModules, reachableTypes)` flow, with a link-preserving `storage.clear()` so cross-schema `resolveType` closures keep working. - **Re-ported the `@ptc-org` patch onto 9.4.0**: removes the `@shareable` federation directive from built-in connection/response types, **and** adds a `.js` extension to its extensionless deep import of `@nestjs/graphql` internals — which v13's new `"exports"` map otherwise rejects at runtime (this was the boot blocker). - **`AppTokenService`**: nestjs-query 9 requires custom services to inject their repo and `super(repo)` it (added an `@InjectRepository` constructor). - **`gridPosition` input fields**: dropped the `deprecationReason` (a *required* input field can't be `@deprecated` under the upgraded graphql) — fields keep their original nullability, so the **schema is unchanged**. - **Service specs**: nestjs-query 9's `TypeOrmQueryService` reads the repo's driver/metadata at construction, so the mocked repos now include `manager`/`metadata`. ## Verification - `nx typecheck twenty-server`: **0 errors**; lint clean - Server boots; **all 3 GraphQL schemas** (`/graphql`, `/metadata`, `/admin-panel`) generate and respond `200` - `graphql:generate` for all 3 schemas is **byte-identical** to before the upgrade (the reachable-types re-port is faithful) - **108 service unit tests pass** (incl. all 6 `TypeOrmQueryService` services) - `ws@8.16.0` gone (now 8.17.1 + 8.18.0); `yarn install --immutable` clean ## Note on lodash `lodash@4.17.21` still remains via `zapier-platform-core` (runtime) and `@stoplight/spectral`, so the lodash alert is **reduced but not fully cleared** by this PR — it needs those separate sources addressed (or a resolution).	2026-06-10 15:55:15 +02:00
Charles Bochet	434f5cbcd2	chore(server): bump @nestjs to 11.1.24 + serve-static 5.0.5 to clear CVEs (#21333) ... Bumps `@nestjs` packages to clear the scanner findings they pin on the prod image. All within-major bumps, past the repo's `npmMinimalAgeGate: 3d`. ## Changes | Package | From → To | Clears | |---|---|---| | `@nestjs/common` | 11.1.16 → **11.1.24** | `file-type@21.3.0` → 21.3.4 | | `@nestjs/core` | ^11.1.18 → **^11.1.24** | (path-to-regexp 8.4.2) | | `@nestjs/platform-express` | 11.1.16 → **11.1.24** | `path-to-regexp@8.3.0` → 8.4.2 | | `@nestjs/serve-static` | 5.0.4 → **5.0.5** | `path-to-regexp@8.3.0` → 8.4.2 | | `@nestjs/testing` | 11.1.16 → **11.1.24** | — | Verified in the regenerated lockfile: **`file-type@21.3.0` and `path-to-regexp@8.3.0` are gone**. `twenty-server:typecheck` passes locally. ## Not in scope - **`lodash@4.17.21`** and **`ws@8.16.0`** are pinned by **`@nestjs/graphql@12.1.1`** (and lodash also by `@nestjs/config@3.3.0`). Bumping graphql 12→13 would clear them, but it's blocked by a **316-line custom patch** implementing Twenty's multi-schema scoping (`resolverSchemaScope`, `computeReachableTypes`) welded to 12.1.1's compiled internals — a dedicated effort, not a routine bump. (Twenty uses the Yoga driver, so it's *not* an Apollo migration.) - `@nestjs/config` 3→4 alone wouldn't clear `lodash` (graphql still pins it), so deferred with the graphql work. - `path-to-regexp@0.1.12` is express 4.x's own — separate from @nestjs.	2026-06-08 19:19:42 +02:00
Charles Bochet	13e8e26d1c	security: bump uuid 9 → 11 (server, shared, front) (#21326) ... Clears the `uuid` "missing buffer bounds check in v3/v5/v6" advisory — patched in **11.1.1**. Bumps `twenty-server`, `twenty-shared`, `twenty-front` from 9 → `^11.1.1`. ### Why 11 and not 13 uuid **11.1.x still ships a CommonJS build**, so jest loads it with **no config changes**. uuid went **ESM-only at v12+**, which would otherwise force `transformIgnorePatterns` workarounds across the jest projects (and broke server/integration/storybook CI on the earlier 13 attempt). 11.1.1 is the actual patched version, so this is the minimal fix. ### Changes - `uuid` → `^11.1.1` in the three workspaces (lockfile regenerated under hardened mode) - one test (`useCreateManyRecords.test.tsx`): pin the mocked `v4` to its string-returning overload — uuid's types declare a `Uint8Array` overload that `jest.mocked` resolves to (present in v11 too, unrelated to ESM). All usages are named imports, so no source migration. typecheck passes (server/shared/front); affected specs pass. **No jest config changes.**	2026-06-08 17:42:19 +02:00
Charles Bochet	d2e7dc0e74	security: bump vulnerable direct dependencies (axios, next, vitest, qs, dompurify, …) (#21309) ... ## What Within-major version bumps of **direct** dependencies to clear a large batch of Dependabot alerts that are breaching (or near) their SLA. No major-version changes — all stay within the current major, so risk is low. | Package | From → To | Clears | |---|---|---| | `axios` | ^1.13.5 → ^1.16.0 | ReDoS, Proxy-Auth leak, proto-pollution gadgets, NO_PROXY bypass, resource DoS (56 alerts) | | `next` | 16.1.7 → ^16.2.6 | DoS, middleware/proxy bypass, SSRF, cache poisoning, XSS (32 alerts) | | `vitest` | 4.0.18 → ^4.1.0 | **CRITICAL** — UI server arbitrary file read/exec (#1421) | | `qs` | ^6.11.2 → ^6.15.2 | `qs.stringify` DoS | | `dompurify` | 3.3.3 → ^3.4.0 | proto-pollution XSS + FORBID_TAGS / SAFE_FOR_TEMPLATES bypasses | | `@nestjs/core` | 11.1.16 → ^11.1.18 | improper output neutralization / injection | | `nodemailer` | 8.0.4 → 8.0.10 | SMTP command injection via CRLF (bumped via root `resolutions`) | | `path-to-regexp` | ^8.2.0 → ^8.4.0 | ReDoS via multiple wildcards | | `file-type` | ^21.3.1 → ^21.3.2 | ZIP decompression-bomb DoS | | `@opentelemetry/exporter-prometheus` | ^0.211.0 → ^0.217.0 | exporter process crash via malformed HTTP request (#1183/#1184) | ## Notes - Added a `next` root **resolution** so the dev-only `@react-email/preview-server` copy (hard-pinned at `16.0.10`) is also pulled up to the patched `16.2.x` line — otherwise that copy keeps the Next.js alerts open. - `@opentelemetry/exporter-prometheus` 0.217 pulled `@opentelemetry/sdk-metrics` to 2.7.1 (compatible); `@opentelemetry/api` stays pinned at 1.9.1. - **Transitive-only** vulnerable packages (undici, tmp, ws, brace-expansion, …) are handled in a **separate PR** per the split-by-group plan. - Breaking major bumps (electron, uuid, serialize-javascript) and migrations (Apollo Server 3→4, simplemde) are intentionally **out of scope** here.	2026-06-08 12:49:31 +00:00
neo773	437eed0862	fix(messaging): fix reply-quotation stripping that emptied email bodies (#21118) ... some synced messages were stored with empty bodies, others with the entire reply thread re-quoted, planer was stripping entirely quoted forwards down to nothing and not trimming inline reply history at all switched plaintext quote stripping to `email-reply-parser`, falling back to the full text when it strips everything so forwards don't end up blank. kept planer for the html path, and normalized body whitespac --------- Co-authored-by: prastoin <paul@twenty.com>	2026-06-04 12:31:53 +00:00
Paul Rastoin	3d49642d12	[AUDIT] Run knip over twenty-server (#21159) ... # Introduction Run [knip](https://knip.dev/) over twenty-server Used config: ```json { "$schema": "https://unpkg.com/knip@5/schema.json", "workspaces": { "packages/twenty-server": { "entry": [ "src/main.ts", "src/command/command.ts", "src/queue-worker/queue-worker.ts", "src/database/scripts/setup-db.ts", "src/database/scripts/truncate-db.ts", "src/database/clickHouse/migrations/run-migrations.ts", "src/database/clickHouse/seeds/run-seeds.ts", "src/instrument.ts", "lingui.config.ts", "test/integration/graphql/codegen/index.ts", "test/integration/utils/setup-test.ts", "test/integration/utils/teardown-test.ts", "scripts/**/*.ts", "**/*.spec.ts", "**/*.integration-spec.ts" ], "project": ["src/**/*.ts", "test/**/*.ts", "scripts/**/*.ts"], "ignore": [ "src/database/typeorm/**/migrations/**", "src/database/typeorm/**/*.entity.ts", "**/*.workspace-entity.ts", "**/logic-function-resource/constants/seed-project/**" ], "ignoreDependencies": ["@types/psl", "@types/aws-lambda"], "ignoreBinaries": ["nest", "lingui", "typeorm"] } } } ```	2026-06-04 10:05:22 +00:00
Charles Bochet	be39702fd2	chore(security): bump protobufjs and esbuild to clear CVEs (#20876) ... ## Summary A self-hoster reported that Trivy blocks the `twentycrm/twenty:v2.7.x` image on three fixed-critical CVEs. The reachable risk is low (none of the vulnerable code paths are exposed to attacker-controlled input in our deployment), but the findings are real and easy to clear by bumping the affected dependencies in their owning workspaces. ### CVE-2026-41242 — `protobufjs` < 7.5.5 Pulled transitively into the production image via `@opentelemetry/sdk-node`, `@opentelemetry/auto-instrumentations-node`, and `@grpc/grpc-js` → `@grpc/proto-loader`. Lockfile was on 7.5.3; this matches dismissed dependabot alert #1009 (Critical 9.4). **Fix:** add `protobufjs: ^7.5.5` as a direct dep of `twenty-server` (the workspace that exercises it via the OpenTelemetry gRPC exporters) and run `yarn dedupe protobufjs` to collapse the residual transitive 7.5.3 copy. Resolves to 7.6.0. ### CVE-2024-24790 and CVE-2025-68121 — Go stdlib in bundled binaries Present in the Go-built `bin/esbuild` shipped by `@esbuild/<platform>` packages. Two paths put esbuild into the production image: 1. `twenty-client-sdk` declares `esbuild` as a runtime dep (used by its `./generate` entry point). 2. `twenty-server` had `@lingui/vite-plugin` in `dependencies`, which pulls `@lingui/cli` as a runtime sub-dep, which bundles `esbuild@0.21.5` nested under `node_modules/@lingui/cli/node_modules/esbuild/`. **Fix:** - Bump `twenty-client-sdk`'s `esbuild` from `^0.25.0` to `^0.27.3` (resolves to 0.27.7, built with patched Go). - Move `@lingui/vite-plugin` from `dependencies` to `devDependencies` in `twenty-server`. The plugin is not imported by any source file — it was misclassified. ### Verification Ran `yarn workspaces focus --production twenty twenty-server twenty-emails twenty-shared twenty-client-sdk` (the same command the Dockerfile uses) and inventoried the resulting `node_modules`. After all three changes: - `node_modules/esbuild/` → **0.27.7 only** (Go-patched) - `node_modules/protobufjs/` → **7.6.0 only** (CVE-patched) No nested copies of either package remain in the production install. ### Follow-up worth tracking separately `esbuild` should arguably not be in `twenty-client-sdk`'s `dependencies` at all — only the `./generate` entry point uses it, and the server never imports that entry. Moving it to optional `peerDependencies` would stop shipping a Go binary into the production image entirely. Out of scope for this PR. ## Test plan - [x] `yarn install` succeeds; `protobufjs` and `esbuild` each resolve to a single version in production focus - [x] `nx build twenty-client-sdk` passes - [x] `nx typecheck twenty-server` passes - [x] `nx build twenty-server` passes - [x] Production focus install confirmed clean (`node_modules/esbuild` and `node_modules/protobufjs` both single-version, both patched) - [ ] CI green - [ ] Re-run Trivy against the resulting image; confirm the three CVEs no longer appear	2026-05-25 12:36:53 +00:00
martmull	0cc2194399	Simplify create-twenty-app command (#20512) ... ## Simplify `create-twenty-app` for zero-interaction use Makes `npx create-twenty-app@latest my-app` a fully non-interactive, single-command experience suitable for automated environments (Codex, Claude plugins). ### Changes - **Remove all interactive prompts** — app name, display name, description, and scaffold confirmation are now derived from CLI args with sensible defaults. `inquirer` dependency removed entirely. - **Replace OAuth with API key auth** — use the seeded dev API key (`DEV_API_KEY`) to authenticate against the Docker instance as `tim@apple.dev`, eliminating the browser-based OAuth flow. - **Docker-first with early validation** — check Docker is installed before scaffolding; if missing, print the install URL and exit. Detect alternative runtimes (Podman, nerdctl). - **Parallel image pull** — `docker pull` runs in the background during scaffold + dependency install, saving 10-30s on typical runs. - **Always pull latest image** — ensures the dev server is up-to-date on every run. - **Stop detecting port 3000** — only check port 2020 (Docker instance). - **Update CLI flags** — remove `--skip-local-instance` and `--yes`; add `--skip-docker`. - **Update CI workflows and docs** — align e2e workflows, package README, and template README/cd.yml with the new flow.	2026-05-13 16:44:27 +00:00
Félix Malfait	4da8878697	feat: add email forwarding message channel (#19535) ... ## Summary - Add email forwarding as a new message channel type, allowing users to forward emails from addresses like `support@mycompany.com` into Twenty - Inbound emails arrive via S3 (SES → S3 bucket), are polled by a cron job, parsed, routed to the correct workspace/channel, and persisted as messages - Dedicated settings page at `/settings/accounts/new-email-forwarding` where users provide their source email handle and receive a unique forwarding address - Forwarding channels bypass the IMAP/mailbox sync state machine — they skip cron-driven sync, relaunch, and message-list-fetch lifecycle stages - Forwarding address section shown at the top of the Emails settings page so users can find/copy their addresses after initial setup - Tab names for forwarding channels display the user-provided handle (e.g. `support@mycompany.com`) instead of the internal routing address - Shared utilities extracted from IMAP driver: `extractThreadId`, `extractParticipants`, `extractAddresses` to avoid code duplication - Uses the existing S3 bucket (STORAGE_S3_*) with `inbound-email/` prefix — no separate bucket needed - Feature gated behind `isEmailForwardingEnabled` client config (requires `INBOUND_EMAIL_DOMAIN` + S3 storage) ## New backend modules - `InboundEmailS3ClientProvider` — lazy-initialized S3 client using existing storage config - `InboundEmailStorageService` — S3 operations (get, move to processed/unmatched/failed) - `InboundEmailParserService` — RFC 822 parsing via `postal-mime`, builds `MessageWithParticipants` - `InboundEmailImportService` — orchestrates download → parse → route → persist → archive - `MessagingInboundEmailPollCronJob` — polls S3 `incoming/` prefix, enqueues import jobs - `CreateEmailForwardingChannelInput` DTO — accepts user-provided `handle` ## New frontend components - `SettingsAccountsNewEmailForwardingChannel` — dedicated page with handle input form + forwarding address result - `SettingsAccountsEmailForwardingSection` — forwarding address list on the Emails settings page - `useConnectedAccountHandleMap` — shared hook for account ID → handle lookup - `useCreateEmailForwardingChannel` — mutation hook accepting handle parameter ## Test plan - [x] 17 unit tests for inbound email import service (all outcomes: imported, unmatched, loop_dropped, unconfigured, parse_failed, persist_failed) - [x] 16 tests for `computeSyncStatus` including EMAIL_FORWARDING cases - [x] 11 tests for `extractEnvelopeRecipient` utility - [x] TypeScript typechecks pass for both twenty-server and twenty-front - [x] Lint passes for both packages - [ ] Manual: create forwarding channel, verify forwarding address generated - [ ] Manual: send email to forwarding address, verify it appears in Twenty https://claude.ai/code/session_01KpyF6p4cUEnuaT4h8DP5Pm --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Copilot Autofix powered by AI <223894421+github-code-quality[bot]@users.noreply.github.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com> Co-authored-by: neo773 <62795688+neo773@users.noreply.github.com> Co-authored-by: neo773 <neo773@protonmail.com>	2026-05-09 11:00:57 +02:00
Etienne	91124a3cb8	AI - Add azure foundry provider (#20170) ... [Merge this before](https://github.com/twentyhq/twenty-infra/pull/655) Co-authored-by: Félix Malfait <felix.malfait@gmail.com>	2026-05-04 14:45:06 +00:00
Charles Bochet	3c7c62c79f	fix(server): deduplicate @opentelemetry/api to fix NoopMeterProvider (#20231) ... ## Summary **All OTel metrics in twenty-server have been silently dropped since April 30.** ### Root cause PR #20149 (`bump @sentry/profiling-node 10.27→10.51`) pulled in `@sentry/node@10.51.0`, which declares `@opentelemetry/api: ^1.9.1` as a **dependency** (not peer). Yarn installed it as a **nested** copy at `1.9.1`, while the hoisted copy stayed at `1.9.0`. At startup in `instrument.ts`: 1. `Sentry.init()` uses the **nested `1.9.1`** to register `trace`, `propagation`, `context` on the OTel global → global version becomes **`1.9.1`** 2. `setGlobalMeterProvider()` uses the **hoisted `1.9.0`** → `registerGlobal` sees version mismatch (`1.9.1` ≠ `1.9.0`) → **silently returns `false`** 3. Global stays `NoopMeterProvider` → every counter, gauge, and histogram in the server is a no-op ### What this PR does 1. **Reverts three troubleshooting PRs** that are no longer needed now that the root cause is identified: - #20230 — heartbeat gauge - #20228 — OTLP export lifecycle logs - #20221 — Sentry revert to 10.27 (which never actually downgraded in `yarn.lock` since `^10.27.0` resolved to `10.51.0`) 2. **Fixes the root cause**: - Root Yarn resolution pinning `@opentelemetry/api` to `1.9.1` → single copy in the entire tree, Sentry and Twenty share the same instance - Named import in `instrument.ts` (`import { metrics as otelMetrics }` instead of default import) as defense-in-depth against CJS interop issues ### Verified on dev cluster Exec'd into the running pod and confirmed: - `@sentry/node` nests `@opentelemetry/api@1.9.1`, hoisted is `1.9.0` - `Sentry.init()` → global version `1.9.1` → `setGlobalMeterProvider` with VERSION `1.9.0` → returns `false` → `NoopMeterProvider` - Same-version registration returns `true` → `MeterProvider` ✓ ## Test plan - [ ] CI passes (lint, typecheck, build) - [ ] Deploy to dev cluster and verify metrics flow to collector - [ ] Confirm `node_modules/@opentelemetry/api/package.json` shows `1.9.1` with no nested copy under `@sentry/` --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-05-04 15:15:00 +02:00
Charles Bochet	ff22988caf	revert: Sentry #20064 + @sentry 10.27 (prod bisect) (#20221) ... ## Summary Reverts **#20064** (`feat(sentry): propagate workspace context to all spans`) and downgrades **@sentry** packages from **10.51** back to **10.27** (reversing **#20149**), to validate in production whether recent Sentry/instrumentation changes correlate with OTLP/metrics issues. ## Changes 1. **Revert #20064** — removes `beforeSendSpan` from `instrument.ts`, restores `WorkspaceAuthContextMiddleware` / `BullMQDriver` behavior, and deletes the three `apply-workspace-sentry-*` utils added in that PR. 2. **Sentry versions** — `packages/twenty-server` (`@sentry/nestjs`, `@sentry/node`, `@sentry/profiling-node`) and `packages/twenty-front` (`@sentry/react`) set to `^10.27.0`; `yarn.lock` regenerated via `yarn install`. --------- Co-authored-by: Cursor <cursoragent@cursor.com>	2026-05-04 11:09:48 +02:00
Paul Rastoin	8a0225e974	Dispatch root package.json hoisted deps and devDeps (#20140) ... # Introduction Dispatching root package.json devDeps, prod deps Taking care of keeping non imported module used at build/ci level in the root package.json ## Motivation Avoid redundant deps declaration, better scoping allow better workspace deps granularity installation. <img width="385" height="247" alt="image" src="https://github.com/user-attachments/assets/9d7162ec-ba01-4f58-8563-38333733fdf0" /> --------- Co-authored-by: Charles Bochet <charles@twenty.com>	2026-04-30 16:50:22 +00:00
dependabot[bot]	83db37d33f	chore(deps): bump @sentry/profiling-node from 10.27.0 to 10.51.0 (#20149) ... Bumps [@sentry/profiling-node](https://github.com/getsentry/sentry-javascript) from 10.27.0 to 10.51.0. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-javascript/releases"><code>@​sentry/profiling-node</code>'s releases</a>.</em></p> <blockquote> <h2>10.51.0</h2> <h3>Important Changes</h3> <ul> <li> <p><strong>feat(cloudflare): Add trace propagation for RPC method calls (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/20343">#20343</a>)</strong></p> <p>Trace context is now propagated across Cloudflare Workers RPC calls, connecting traces between Workers and Durable Objects. This feature is opt-in and requires setting <code>enableRpcTracePropagation: true</code> in your SDK configuration:</p> <pre lang="ts"><code>// Worker export default Sentry.withSentry( env =&gt; ({ dsn: env.SENTRY_DSN, enableRpcTracePropagation: true, }), handler, ); <p>// Durable Object<br /> export const MyDurableObject = Sentry.instrumentDurableObjectWithSentry(<br /> env =&gt; ({<br /> dsn: env.SENTRY_DSN,<br /> enableRpcTracePropagation: true,<br /> }),<br /> MyDurableObjectBase,<br /> );<br /> </code></pre></p> </li> <li> <p><strong>feat(hono)!: Change setup for <code>@sentry/hono/node</code> (<code>init</code> in external file) (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/20497">#20497</a>)</strong></p> <p>To improve Node.js instrumentation, the <code>sentry()</code> middleware exported from <code>@sentry/hono/node</code> no longer accepts configuration options. Instead, you must configure the SDK by calling <code>Sentry.init()</code> in a dedicated instrumentation file that runs before your application code (read more in the <a href="https://github.com/getsentry/sentry-javascript/blob/develop/packages/hono/README.md">Hono SDK readme</a>:</p> <pre lang="ts"><code>// instrument.mjs (or instrument.ts) import * as Sentry from '@sentry/hono/node'; <p>Sentry.init({<br /> dsn: '<strong>DSN</strong>',<br /> tracesSampleRate: 1.0,<br /> });<br /> </code></pre></p> </li> <li> <p><strong>feat(nitro): Add <code>@sentry/nitro</code> SDK (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/19224">#19224</a>)</strong></p> <p>A new <code>@sentry/nitro</code> package provides first-class Sentry support for <a href="https://nitro.build/">Nitro</a> applications, with HTTP handler and error instrumentation, middleware tracing, request isolation, and build-time source map uploading via <code>withSentryConfig</code>. Read more in the <a href="https://docs.sentry.io/platforms/javascript/guides/nitro/">Nitro SDK docs</a> and the <a href="https://github.com/getsentry/sentry-javascript/blob/develop/packages/nitro/README.md">Nitro SDK readme</a>.</p> </li> </ul> <h3>Other Changes</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/getsentry/sentry-javascript/blob/develop/CHANGELOG.md"><code>@​sentry/profiling-node</code>'s changelog</a>.</em></p> <blockquote> <h2>10.51.0</h2> <h3>Important Changes</h3> <ul> <li> <p><strong>feat(cloudflare): Add trace propagation for RPC method calls (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/20343">#20343</a>)</strong></p> <p>Trace context is now propagated across Cloudflare Workers RPC calls, connecting traces between Workers and Durable Objects. This feature is opt-in and requires setting <code>enableRpcTracePropagation: true</code> in your SDK configuration:</p> <pre lang="ts"><code>// Worker export default Sentry.withSentry( env =&gt; ({ dsn: env.SENTRY_DSN, enableRpcTracePropagation: true, }), handler, ); <p>// Durable Object<br /> export const MyDurableObject = Sentry.instrumentDurableObjectWithSentry(<br /> env =&gt; ({<br /> dsn: env.SENTRY_DSN,<br /> enableRpcTracePropagation: true,<br /> }),<br /> MyDurableObjectBase,<br /> );<br /> </code></pre></p> </li> <li> <p><strong>feat(hono)!: Change setup for <code>@sentry/hono/node</code> (<code>init</code> in external file) (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/20497">#20497</a>)</strong></p> <p>To improve Node.js instrumentation, the <code>sentry()</code> middleware exported from <code>@sentry/hono/node</code> no longer accepts configuration options. Instead, you must configure the SDK by calling <code>Sentry.init()</code> in a dedicated instrumentation file that runs before your application code (read more in the <a href="https://github.com/getsentry/sentry-javascript/blob/develop/packages/hono/README.md">Hono SDK readme</a>:</p> <pre lang="ts"><code>// instrument.mjs (or instrument.ts) import * as Sentry from '@sentry/hono/node'; <p>Sentry.init({<br /> dsn: '<strong>DSN</strong>',<br /> tracesSampleRate: 1.0,<br /> });<br /> </code></pre></p> </li> <li> <p><strong>feat(nitro): Add <code>@sentry/nitro</code> SDK (<a href="https://redirect.github.com/getsentry/sentry-javascript/pull/19224">#19224</a>)</strong></p> <p>A new <code>@sentry/nitro</code> package provides first-class Sentry support for <a href="https://nitro.build/">Nitro</a> applications, with HTTP handler and error instrumentation, middleware tracing, request isolation, and build-time source map uploading via <code>withSentryConfig</code>. Read more in the <a href="https://docs.sentry.io/platforms/javascript/guides/nitro/">Nitro SDK docs</a> and the <a href="https://github.com/getsentry/sentry-javascript/blob/develop/packages/nitro/README.md">Nitro SDK readme</a>.</p> </li> </ul> <h3>Other Changes</h3> <!-- raw HTML omitted --> </blockquote> <p>... (truncated)</p> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/getsentry/sentry-javascript/commit/dc0b839ff4896cf90a02f5c1a6de54a31302dcf3"><code>dc0b839</code></a> release: 10.51.0</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/b3cabee9a9348b9e67332262d44d3d1900424199"><code>b3cabee</code></a> Merge pull request <a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20599">#20599</a> from getsentry/prepare-release/10.51.0</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/3be99a9afa77e49578e6839e4b32f97fb04fb0f8"><code>3be99a9</code></a> meta(changelog): Update changelog for 10.51.0</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/bea1aad42277db894d5a299bfec3cdd633d6baf0"><code>bea1aad</code></a> test(browser): Unflake some more tests (<a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20591">#20591</a>)</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/50aa0859b3a188d34d0317dab3ad57f2140f02fe"><code>50aa085</code></a> test(node): Unflake postgres tests (<a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20593">#20593</a>)</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/1166839112c4766f210124dc0486ebbfd6db104b"><code>1166839</code></a> fix(hono): Distinguish <code>.use()</code> middleware in sub-apps from <code>.all()</code> handlers...</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/217ad4a69554281806eccbfeac1b27c4f43f6ffa"><code>217ad4a</code></a> test(node): Fix flaky ANR test (<a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20592">#20592</a>)</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/91ffb3fac90835ab160f8152527a54a5d64f3250"><code>91ffb3f</code></a> test(node): Fix flaky worker thread integration test (<a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20588">#20588</a>)</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/c4e3902c9297147158e730f017aba96e83ef619e"><code>c4e3902</code></a> chore(ci): Do not report flaky test issues if we cannot find a test name (<a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20">#20</a>...</li> <li><a href="https://github.com/getsentry/sentry-javascript/commit/c0005cd387f3a7ea6fbb2e85041562c7f32e0484"><code>c0005cd</code></a> test(node): Update timeout for cron integration tests (<a href="https://redirect.github.com/getsentry/sentry-javascript/issues/20586">#20586</a>)</li> <li>Additional commits viewable in <a href="https://github.com/getsentry/sentry-javascript/compare/10.27.0...10.51.0">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Charles Bochet <charles@twenty.com>	2026-04-30 12:02:34 +00:00
neo773	a713f8d87f	CalDAV: support Digest auth (#20135) ... Adds digest auth support for CalDAV, mostly used by legacy servers /closes https://github.com/twentyhq/twenty/issues/19922	2026-04-29 16:09:21 +00:00
Etienne	fd6d5f895d	Ai Chat - Caching optim (#20126) ... EDIT : - solving auto-caching from Anthropic by updating ai-sdk/anthropic + adding providerOption at stream level - concerning Bedrock, it needs breakpoint **1. Breakpoints were only on the system prompt** The code already placed a cache marker on the system prompt (~10K tokens). But the conversation history — which can grow to hundreds of thousands of tokens — had no marker, so Anthropic re-read it at full price on every turn. The fix adds a prepareStep hook inside streamText that stamps the last message with a cache breakpoint before every LLM call. Anthropic then caches the entire conversation prefix, and subsequent turns read it at $0.30/M instead of $3/M. prepareStep is used rather than a one-shot pre-processing step because an agentic turn makes multiple internal LLM calls as tool results accumulate — the hook refreshes the breakpoint before each one. **2. Bedrock was using the wrong field** The system prompt marker for Bedrock was set as cacheControl: { type: 'ephemeral' } — which is the Anthropic wire format. The Bedrock Converse API expects cachePoint: { type: 'default' }. The system prompt was silently not being cached on Bedrock at all. Both the system prompt and the new prepareStep now go through a shared getCacheProviderOptions helper that returns the correct field per provider. **3. Persisted cached token usage to monitor cache strat. efficiency**	2026-04-29 14:42:12 +00:00
neo773	abfa6200dd	ssrf hardening (#19963) ... Hardened CalDav with new approach of wrapping axios ssrf http agent to fetch via `@lifeomic/axios-fetch` because `tsdav` only accept `fetch` override. Also Hardened test endpoint	2026-04-29 12:13:19 +00:00
dependabot[bot]	80e8f6d516	chore(deps): bump @blocknote/server-util from 0.47.1 to 0.47.3 (#19997) ... Bumps [@blocknote/server-util](https://github.com/TypeCellOS/BlockNote/tree/HEAD/packages/server-util) from 0.47.1 to 0.47.3. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/TypeCellOS/BlockNote/releases"><code>@​blocknote/server-util</code>'s releases</a>.</em></p> <blockquote> <h2>v0.47.3</h2> <h2>0.47.3 (2026-03-25)</h2> <h3>🩹 Fixes</h3> <ul> <li><strong>core:</strong> preserve whitespace edge cases but collapse html formatting newlines (BLO-1065) (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2551">#2551</a>, <a href="https://redirect.github.com/TypeCellOS/BlockNote/issues/2230">#2230</a>)</li> </ul> <h3>❤️ Thank You</h3> <ul> <li>Yousef</li> </ul> <h2>v0.47.2</h2> <h2>0.47.2 (2026-03-20)</h2> <h3>🩹 Fixes</h3> <ul> <li>use <code>&lt;details&gt;</code> &amp; <code>&lt;summary&gt;</code> for toggle block HTML export (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2524">#2524</a>)</li> <li>remove <code>@hocuspocus/provider</code> peer dependency by inlining tiptap comment types BLO-1064 (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2564">#2564</a>)</li> <li><strong>core:</strong> slash menu fails in custom blocks after space BLO-1036 (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2553">#2553</a>)</li> <li><strong>i18n:</strong> fix typo in russian translation (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2560">#2560</a>)</li> </ul> <h3>❤️ Thank You</h3> <ul> <li>Drone</li> <li>Yousef</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/TypeCellOS/BlockNote/blob/main/CHANGELOG.md"><code>@​blocknote/server-util</code>'s changelog</a>.</em></p> <blockquote> <h2>0.47.3 (2026-03-25)</h2> <h3>🩹 Fixes</h3> <ul> <li><strong>core:</strong> preserve whitespace edge cases but collapse html formatting newlines (BLO-1065) (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2551">#2551</a>, <a href="https://redirect.github.com/TypeCellOS/BlockNote/issues/2230">#2230</a>)</li> </ul> <h3>❤️ Thank You</h3> <ul> <li>Yousef</li> </ul> <h2>0.47.2 (2026-03-20)</h2> <h3>🩹 Fixes</h3> <ul> <li>use <!-- raw HTML omitted -->/<!-- raw HTML omitted --> for toggle block HTML export (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2524">#2524</a>)</li> <li>remove <code>@​hocuspocus/provider</code> peer dependency by inlining tiptap comment types BLO-1064 (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2564">#2564</a>)</li> <li><strong>core:</strong> slash menu fails in custom blocks after space BLO-1036 (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2553">#2553</a>)</li> <li><strong>i18n:</strong> fix typo in russian translation (<a href="https://redirect.github.com/TypeCellOS/BlockNote/pull/2560">#2560</a>)</li> </ul> <h3>❤️ Thank You</h3> <ul> <li>Claude Opus 4.6</li> <li>Drone</li> <li>Yousef</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/TypeCellOS/BlockNote/commit/cd92dc21be49397b658fef4e308e01ce8f5c04ad"><code>cd92dc2</code></a> chore(release): publish 0.47.3</li> <li><a href="https://github.com/TypeCellOS/BlockNote/commit/b63b4096daa575f821980ef897fd90f4c76d9e42"><code>b63b409</code></a> chore(release): publish 0.47.2</li> <li><a href="https://github.com/TypeCellOS/BlockNote/commit/d76fd68e016da698f3896f9d349a935a26a52d5f"><code>d76fd68</code></a> test: get snapshots working again (<a href="https://github.com/TypeCellOS/BlockNote/tree/HEAD/packages/server-util/issues/2554">#2554</a>)</li> <li>See full diff in <a href="https://github.com/TypeCellOS/BlockNote/commits/v0.47.3/packages/server-util">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> --------- Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Abdullah <125115953+mabdullahabaid@users.noreply.github.com>	2026-04-23 07:29:45 +00:00
Paul Rastoin	9a403b84f3	database:init:prod triggers instance slow command too (#19555) ... When creating a db from scrath we still need to run the slow instance command so the associated queries are still applied to the empty db Please note that by default if there's no workspace the instance slow runner will skip the runDataMigration part	2026-04-10 13:19:19 +00:00
BugIsGod	8a84e32cf6	fix(ai): use @ai-sdk/openai-compatible for third-party providers (#19438) ... ## Summary: I found a bug: 404 call when I use third-party providers (I used deepseek). I found the final request url is: `https://api.deepseek.com/v1/responses' `if we use createOpenAI. But the correct one should be `https://api.provider.com/v1/chat/completions` for the thirty provider. So I replace createOpenAI with createOpenAICompatible in the openai-compatible provider path. **Reproduction**: Add DeepSeek as a new AI provider (deepseek-chat, deepseek-reasoner) Also check the source code in Open Code project, they also use createOpenAICompatible for the @ai-sdk/openai-compatible scenario <img width="703" height="369" alt="image" src="https://github.com/user-attachments/assets/90c4f924-6f1a-4fe7-821b-f13ee86a7a39" /> official docs: https://ai-sdk.dev/providers/openai-compatible-providers https://ai-sdk.dev/providers/ai-sdk-providers/openai <img width="860" height="293" alt="image" src="https://github.com/user-attachments/assets/283b9b91-f1d6-4b1c-bb91-16ddccdff8b4" /> ## Before <img width="473" height="750" alt="deepseek before" src="https://github.com/user-attachments/assets/f6b89294-1fa7-4ddc-a6a8-d396070caaca" /> ## After <img width="468" height="753" alt="deepseek after" src="https://github.com/user-attachments/assets/0d170b70-e829-4a4c-abad-38879427c2df" /> ## Backend error log ```json [1] [Nest] 50907 - 07/04/2026, 23:48:57 LOG [ChatExecutionService] Starting chat execution with model deepseek/deepseek-chat, 4 active tools [1] APICallError [AI_APICallError]: Not Found [1] at /Users/abel/Documents/Code/twenty/node_modules/@ai-sdk/provider-utils/dist/index.js:2512:14 [1] at process.processTicksAndRejections (node:internal/process/task_queues:105:5) [1] at async postToApi (/Users/abel/Documents/Code/twenty/node_modules/@ai-sdk/provider-utils/dist/index.js:2373:28) [1] at async OpenAIResponsesLanguageModel.doStream (/Users/abel/Documents/Code/twenty/node_modules/@ai-sdk/openai/dist/index.js:4925:50) [1] at async fn (/Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:7106:27) [1] at async /Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:2340:24 [1] at async _retryWithExponentialBackoff (/Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:2599:12) [1] at async streamStep (/Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:7063:17) [1] at async fn (/Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:7455:9) [1] at async /Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:2340:24 { [1] cause: undefined, [1] url: 'https://api.deepseek.com/v1/responses', [1] requestBodyValues: { [1] model: 'deepseek-chat', [1] input: [ [Object], [Object] ], [1] temperature: undefined, [1] top_p: undefined, [1] max_output_tokens: undefined, [1] conversation: undefined, [1] max_tool_calls: undefined, [1] metadata: undefined, [1] parallel_tool_calls: undefined, [1] previous_response_id: undefined, [1] store: undefined, [1] user: undefined, [1] instructions: undefined, [1] service_tier: undefined, [1] include: undefined, [1] prompt_cache_key: undefined, [1] prompt_cache_retention: undefined, [1] safety_identifier: undefined, [1] top_logprobs: undefined, [1] truncation: undefined, [1] tools: [ [Object], [Object], [Object], [Object] ], [1] tool_choice: 'auto', [1] stream: true [1] }, [1] statusCode: 404, [1] responseHeaders: { [1] 'access-control-allow-credentials': 'true', [1] connection: 'keep-alive', [1] 'content-length': '0', [1] date: 'Tue, 07 Apr 2026 22:48:57 GMT', [1] server: 'elb', [1] 'strict-transport-security': 'max-age=31536000; includeSubDomains; preload', [1] vary: 'origin, access-control-request-method, access-control-request-headers', [1] via: '1.1 83867089cd39052cd05f9e04909bedde.cloudfront.net (CloudFront)', [1] 'x-amz-cf-id': 'O4b0VTi9Q1VVmTmq6czGlEWst7IPnAQl544hB7uIvfnSphBvUKbZTw==', [1] 'x-amz-cf-pop': 'DUB56-P3', [1] 'x-cache': 'Error from cloudfront', [1] 'x-content-type-options': 'nosniff', [1] 'x-ds-trace-id': 'a90e91809d285170338ef077f67ae2be' [1] }, [1] responseBody: '', [1] isRetryable: false, [1] data: undefined, [1] Symbol(vercel.ai.error): true, [1] Symbol(vercel.ai.error.AI_APICallError): true [1] } [1] Exception Captured [1] undefined [1] [ [1] NoOutputGeneratedError [AI_NoOutputGeneratedError]: No output generated. Check the stream for errors. [1] at Object.flush (/Users/abel/Documents/Code/twenty/node_modules/ai/dist/index.js:6656:103) [1] at invokePromiseCallback (node:internal/webstreams/util:172:10) [1] at Object.<anonymous> (node:internal/webstreams/util:177:23) [1] at transformStreamDefaultSinkCloseAlgorithm (node:internal/webstreams/transformstream:621:43) [1] at node:internal/webstreams/transformstream:379:11 [1] at writableStreamDefaultControllerProcessClose (node:internal/webstreams/writablestream:1162:28) [1] at writableStreamDefaultControllerAdvanceQueueIfNeeded (node:internal/webstreams/writablestream:1253:5) [1] at writableStreamDefaultControllerClose (node:internal/webstreams/writablestream:1220:3) [1] at writableStreamClose (node:internal/webstreams/writablestream:722:3) [1] at writableStreamDefaultWriterClose (node:internal/webstreams/writablestream:1091:10) { [1] cause: undefined, [1] Symbol(vercel.ai.error): true, [1] Symbol(vercel.ai.error.AI_NoOutputGeneratedError): true [1] } [1] ] [1] [Nest] 50907 - 07/04/2026, 23:48:59 LOG [BullMQDriver] Job 24 with name StreamAgentChatJob processed on queue ai-stream-queue in 2756.63ms	2026-04-08 12:01:49 +00:00
Etienne	1b14e7e1f1	Fix - Update package.json (#19390) ... https://github.com/twentyhq/twenty/pull/19383#discussion_r3044330450	2026-04-07 11:44:23 +00:00
Paul Rastoin	23874848a4	Instance commands and upgrade_migrations table (#19356) ... # Introduction Now only using typeorm to generate migrations up and down statement We handle and maintain our own migration table history ## What's new Now all the instance commands will live within the same module and folder than the upgrade commands Sequentiality comes from the timestamp located in the filename Same sequentiality also applies to the workspace commands in the future, for the moment still expected a as code explicit declaration ( below screen is an example see below section ) <img width="1382" height="634" alt="image" src="https://github.com/user-attachments/assets/5610a246-4eae-485e-99f4-98fb89ad5ac8" /> ## Existing 1.21 migrations We won't start following this pattern in 1.21 yet at least not with the migration that has already been released as typeorm migrations in cloud production as they would rerun ## Small duplication Duplicating the legacy typeorm and instance commands run in the `run-instance-commands` to avoid any merge of interest for the moment ## Concurrency Not handling any run in parrallel of the upgrade for the moment	2026-04-07 08:55:17 +00:00