250 Commits

Author	SHA1	Message	Date
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
Félix Malfait	ea572975d8	feat: generic web search driver abstraction with Exa support and billing (#19341) ... ## Summary - Introduces a pluggable `WebSearchDriver` abstraction (interface, factory, service, module) so web search is no longer tied to native provider tools (Anthropic/OpenAI) - **Exa** is the first driver implementation with support for category-filtered search (company, people, news, research paper, etc.) — particularly useful for CRM workflows - Per-query billing for both Exa ($0.007/query) and native provider surcharges ($0.01/query for Anthropic/OpenAI) via the existing `USAGE_RECORDED` pipeline - New config variables: `WEB_SEARCH_DRIVER` (EXA/DISABLED), `EXA_API_KEY`, `WEB_SEARCH_PREFER_NATIVE` (default false — prefers Exa over native when both available) - `WEB_SEARCH` operation type added for usage tracking and Stripe metering ### Architecture ``` WebSearchDriver (interface) ├── ExaDriver — Exa neural search with category support └── DisabledDriver — throws when search is disabled WebSearchDriverFactory (extends DriverFactoryBase) └── creates driver based on WEB_SEARCH_DRIVER config WebSearchService (facade) ├── search(query, options?, billingContext?) ├── isEnabled() └── emits USAGE_RECORDED events per query WebSearchTool (Tool implementation) └── registered in ActionToolProvider, available via tool catalog ``` ### Native search billing gap fixed Anthropic and OpenAI both charge $0.01/search on top of token costs. The token costs were already billed, but the per-call surcharge was not. Added `countNativeWebSearchCallsFromSteps` utility + `billNativeWebSearchUsage` to `AiBillingService`, wired into both chat and workflow agent paths. ## Test plan - [ ] Set `WEB_SEARCH_DRIVER=EXA` + `EXA_API_KEY=...` and verify AI chat can search the web - [ ] Verify category parameter works (ask about a specific company/person) - [ ] Set `WEB_SEARCH_DRIVER=DISABLED` and verify search tool is not exposed - [ ] Set `WEB_SEARCH_PREFER_NATIVE=true` with Anthropic model and verify native search is used - [ ] Verify usage events are emitted in ClickHouse for both Exa and native search paths - [ ] Verify existing billing tests pass (`npx jest ai-billing.service.spec.ts`) Made with [Cursor](https://cursor.com) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: claude[bot] <41898282+claude[bot]@users.noreply.github.com>	2026-04-06 12:02:46 +02:00
Paul Rastoin	e062343802	Refactor typeorm migration lifecycle and generation (#19275) ... # Introduction Typeorm migration are now associated to a given twenty-version from the `UPGRADE_COMMAND_SUPPORTED_VERSIONS` that the current twenty core engine handles This way when we upgrade we retrieve the migrations that need to be run, this will be useful for the cross-version incremental upgrade so we preserve sequentiality ## What's new To generate ```sh npx nx database:migrate:generate twenty-server -- --name add-index-to-users ``` To apply all ```sh npx nx database:migrate twenty-server ``` ## Next Introduce slow and fast typeorm migration in order to get rid of the save point pattern in our code base Create a clean and dedicated `InstanceUpgradeService` abstraction	2026-04-06 07:11:47 +00:00
Félix Malfait	fd7387928c	feat: queue messages + replace AI SDK with GraphQL SSE subscription (#19203) ... ## Summary - **Queue messages while streaming**: Messages sent during active AI streaming are queued server-side and auto-flushed when the current stream completes. Frontend renders queued messages optimistically in a dedicated queue UI. - **Drop `@ai-sdk/react` + `resumable-stream`**: Replace the dual HTTP SSE + AI SDK client architecture with a single GraphQL SSE subscription per thread. All events (token chunks, message persistence, queue updates, errors) flow through Redis PubSub → GraphQL subscription. - **Server-driven architecture**: The server decides whether to queue or stream (via `POST /:threadId/message`). The frontend mirrors this decision for optimistic rendering but defers to the server response. - **Reuse AI SDK accumulation logic**: `readUIMessageStream` from the `ai` package handles chunk-to-message accumulation on the frontend, avoiding a custom 780-line accumulator. ## Key files **Backend:** - `agent-chat-event-publisher.service.ts` — publishes events to Redis PubSub - `agent-chat-subscription.resolver.ts` — GraphQL subscription resolver - `stream-agent-chat.job.ts` — publishes chunks via PubSub instead of resumable-stream - `agent-chat.controller.ts` — unified `POST /:threadId/message` endpoint **Frontend:** - `useAgentChatSubscription.ts` — subscribes to `onAgentChatEvent`, bridges to `readUIMessageStream` - `useAgentChat.ts` — send/stop/optimistic rendering (no more AI SDK) - `AgentChatStreamSubscriptionEffect.tsx` — replaces `AgentChatAiSdkStreamEffect.tsx` ## Test plan - [ ] Send message on new thread → optimistic render, streaming response appears - [ ] Send message while streaming → queued instantly (no flash in main thread) - [ ] Queued message auto-flushes after current stream completes - [ ] Remove queued message via queue UI - [ ] Stop streaming mid-response - [ ] Leave chat idle for several minutes → streaming still works after (SSE client recycling) - [ ] Token refresh during session → requests succeed (authenticated fetch) - [ ] Switch threads while streaming → clean subscription handoff Made with [Cursor](https://cursor.com) --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>	2026-04-02 10:10:13 +02:00
Gabriel	36dece43c7	Fix: Upgrade Nodemailer to address SMTP command injection vulnerability (#19151) ... 📄 Summary This PR upgrades the nodemailer dependency to a secure version (≥ 8.0.4) to fix a known SMTP command injection vulnerability (GHSA-c7w3-x93f-qmm8). 🚨 Issue The current version used in twenty-server (^7.0.11, resolved to 7.0.11 / 7.0.13) is vulnerable to SMTP command injection due to improper sanitization of the envelope.size parameter. This could allow CRLF injection, potentially enabling attackers to add unauthorized recipients to outgoing emails. 🔍 Root Cause The vulnerability originates from insufficient validation of user-controlled input in the SMTP envelope, specifically the size field, which can be exploited via crafted input containing CRLF sequences. ✅ Changes Upgraded nodemailer to version ^8.0.4 Ensured compatibility with existing email sending logic Verified that no breaking changes affect current usage 🔐 Security Impact This update mitigates the risk of: SMTP command injection Unauthorized email recipient manipulation Potential data leakage via crafted email payloads 📎 References GHSA: GHSA-c7w3-x93f-qmm8 CVE: (see linked report in issue) --------- Co-authored-by: Félix Malfait <felix.malfait@gmail.com> Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>	2026-03-31 19:55:50 +00:00
Félix Malfait	8fa3962e1c	feat: add resumable stream support for agent chat (#19107) ... ## Overview Add resumable stream support for agent chat to allow clients to reconnect and resume streaming responses if the connection is interrupted (e.g., during page refresh). ## Changes ### Backend (Twenty Server) - Add `activeStreamId` column to `AgentChatThreadEntity` to track ongoing streams - Create `AgentChatResumableStreamService` to manage Redis-backed resumable streams using the `resumable-stream` library with ioredis - Extend `AgentChatController` with: - `GET /:threadId/stream` endpoint to resume an existing stream - `DELETE /:threadId/stream` endpoint to stop an active stream - Update `AgentChatStreamingService` to store streams in Redis and track active stream IDs - Add `resumable-stream@^2.2.12` dependency to package.json ### Frontend (Twenty Front) - Update `useAgentChat` hook to: - Use a persistent transport with `prepareReconnectToStreamRequest` for resumable streams - Export `resumeStream` function from useChat - Add `handleStop` callback to clear active stream on DELETE endpoint - Use thread ID as stable message ID instead of including message count - Add stream resumption logic in `AgentChatAiSdkStreamEffect` component to automatically call `resumeStream()` when switching threads ## Database Migration New migration `1774003611071-add-active-stream-id-to-agent-chat-thread` adds the `activeStreamId` column to store the current resumable stream identifier. --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>	2026-03-30 18:19:25 +02:00
Paul Rastoin	281bb6d783	Guard yarn database:migrate:prod (#19008) ... ## Motivations A lot of self hosters hands up using the `yarn database:migrated:prod` either manually or through AI assisted debug while they try to upgrade an instance while their workspace is still blocked in a previous one Leading to their whole database permanent corruption ## What happened Replaced the direct call the the typeorm cli to a command calling it programmatically, adding a layer of security in case a workspace seems to be blocked in a previous version than the one just before the one being installed ( e.g 1.0 when you try to upgrade from 1.1 to 1.2 ) For our cloud we still need a way to bypass this security explaining the -f flag ## Remark Centralized this logic and refactored creating new services `WorkspaceVersionService` and `CoreEngineVersionService` that will become useful for the upcoming upgrade refactor Related to https://github.com/twentyhq/twenty-infra/pull/529	2026-03-27 14:39:18 +00:00
Paul Rastoin	4ea2e32366	Refactor twenty client sdk provisioning for logic function and front-component (#18544) ... ## 1. The `twenty-client-sdk` Package (Source of Truth) The monorepo package at `packages/twenty-client-sdk` ships with: - A **pre-built metadata client** (static, generated from a fixed schema) - A **stub core client** that throws at runtime (`CoreApiClient was not generated...`) - Both ESM (`.mjs`) and CJS (`.cjs`) bundles in `dist/` - A `package.json` with proper `exports` map for `twenty-client-sdk/core`, `twenty-client-sdk/metadata`, and `twenty-client-sdk/generate` ## 2. Generation & Upload (Server-Side, at Migration Time) **When**: `WorkspaceMigrationRunnerService.run()` executes after a metadata schema change. **What happens in `SdkClientGenerationService.generateAndStore()`**: 1. Copies the stub `twenty-client-sdk` package from the server's assets (resolved via `SDK_CLIENT_PACKAGE_DIRNAME` — from `dist/assets/twenty-client-sdk/` in production, or from `node_modules` in dev) 2. Filters out `node_modules/` and `src/` during copy — only `package.json` + `dist/` are kept (like an npm publish) 3. Calls `replaceCoreClient()` which uses `@genql/cli` to introspect the **application-scoped** GraphQL schema and generates a real `CoreApiClient`, then compiles it to ESM+CJS and overwrites `dist/core.mjs` and `dist/core.cjs` 4. Archives the **entire package** (with `package.json` + `dist/`) into `twenty-client-sdk.zip` 5. Uploads the single archive to S3 under `FileFolder.GeneratedSdkClient` 6. Sets `isSdkLayerStale = true` on the `ApplicationEntity` in the database ## 3. Invalidation Signal The `isSdkLayerStale` boolean column on `ApplicationEntity` is the invalidation mechanism: - **Set to `true`** by `generateAndStore()` after uploading a new client archive - **Checked** by both logic function drivers before execution — if `true`, they rebuild their local layer - **Set back to `false`** by `markSdkLayerFresh()` after the driver has successfully consumed the new archive Default is `false` so existing applications without a generated client aren't affected. ## 4a. Logic Functions — Local Driver **`ensureSdkLayer()`** is called before every execution: 1. Checks if the local SDK layer directory exists AND `isSdkLayerStale` is `false` → early return 2. Otherwise, cleans the local layer directory 3. Calls `downloadAndExtractToPackage()` which streams the zip from S3 directly to disk and extracts the full package into `<tmpdir>/sdk/<workspaceId>-<appId>/node_modules/twenty-client-sdk/` 4. Calls `markSdkLayerFresh()` to set `isSdkLayerStale = false` **At execution time**, `assembleNodeModules()` symlinks everything from the deps layer's `node_modules/` **except** `twenty-client-sdk`, which is symlinked from the SDK layer instead. This ensures the logic function's `import ... from 'twenty-client-sdk/core'` resolves to the generated client. ## 4b. Logic Functions — Lambda Driver **`ensureSdkLayer()`** is called during `build()`: 1. Checks if `isSdkLayerStale` is `false` and an existing Lambda layer ARN exists → early return 2. Otherwise, deletes all existing layer versions for this SDK layer name 3. Calls `downloadArchiveBuffer()` to get the raw zip from S3 (no disk extraction) 4. Calls `reprefixZipEntries()` which streams the zip entries into a **new zip** with the path prefix `nodejs/node_modules/twenty-client-sdk/` — this is the Lambda layer convention path. All done in memory, no disk round-trip 5. Publishes the re-prefixed zip as a new Lambda layer via `publishLayer()` 6. Calls `markSdkLayerFresh()` **At function creation**, the Lambda is created with **two layers**: `[depsLayerArn, sdkLayerArn]`. The SDK layer is listed last so it overwrites the stub `twenty-client-sdk` from the deps layer (later layers take precedence in Lambda's `/opt` merge). ## 5. Front Components Front components are built by `app:build` with `twenty-client-sdk/core` and `twenty-client-sdk/metadata` as **esbuild externals**. The stored `.mjs` in S3 has unresolved bare import specifiers like `import { CoreApiClient } from 'twenty-client-sdk/core'`. SDK import resolution is split between the **frontend host** (fetching & caching SDK modules) and the **Web Worker** (rewriting imports): **Server endpoints**: - `GET /rest/front-components/:id` — `FrontComponentService.getBuiltComponentStream()` returns the **raw `.mjs`** directly from file storage. No bundling, no SDK injection. - `GET /rest/sdk-client/:applicationId/:moduleName` — `SdkClientController` reads a single file (e.g. `dist/core.mjs`) from the generated SDK archive via `SdkClientGenerationService.readFileFromArchive()` and serves it as JavaScript. **Frontend host** (`FrontComponentRenderer` in `twenty-front`): 1. Queries `FindOneFrontComponent` which returns `applicationId`, `builtComponentChecksum`, `usesSdkClient`, and `applicationTokenPair` 2. If `usesSdkClient` is `true`, renders `FrontComponentRendererWithSdkClient` which calls the `useApplicationSdkClient` hook 3. `useApplicationSdkClient({ applicationId, accessToken })` checks the Jotai atom family cache for existing blob URLs. On cache miss, fetches both SDK modules from `GET /rest/sdk-client/:applicationId/core` and `/metadata`, creates **blob URLs** for each, and stores them in the atom family 4. Once the blob URLs are cached, passes them as `sdkClientUrls` (already blob URLs, not server URLs) to `SharedFrontComponentRenderer` → `FrontComponentWorkerEffect` → worker's `render()` call via `HostToWorkerRenderContext` **Worker** (`remote-worker.ts` in `twenty-sdk`): 1. Fetches the raw component `.mjs` source as text 2. If `sdkClientUrls` are provided and the source contains SDK import specifiers (`twenty-client-sdk/core`, `twenty-client-sdk/metadata`), **rewrites** the bare specifiers to the blob URLs received from the host (e.g. `'twenty-client-sdk/core'` → `'blob:...'`) 3. Creates a blob URL for the rewritten source and `import()`s it 4. Revokes only the component blob URL after the module is loaded — the SDK blob URLs are owned and managed by the host's Jotai cache This approach eliminates server-side esbuild bundling on every request, caches SDK modules per application in the frontend, and keeps the worker's job to a simple string rewrite. ## Summary Diagram ``` app:build (SDK) └─ twenty-client-sdk stub (metadata=real, core=stub) │ ▼ WorkspaceMigrationRunnerService.run() └─ SdkClientGenerationService.generateAndStore() ├─ Copy stub package (package.json + dist/) ├─ replaceCoreClient() → regenerate core.mjs/core.cjs ├─ Zip entire package → upload to S3 └─ Set isSdkLayerStale = true │ ┌────────┴────────────────────┐ ▼ ▼ Logic Functions Front Components │ │ ├─ Local Driver ├─ GET /rest/sdk-client/:appId/core │ └─ downloadAndExtract │ → core.mjs from archive │ → symlink into │ │ node_modules ├─ Host (useApplicationSdkClient) │ │ ├─ Fetch SDK modules └─ Lambda Driver │ ├─ Create blob URLs └─ downloadArchiveBuffer │ └─ Cache in Jotai atom family → reprefixZipEntries │ → publish as Lambda ├─ GET /rest/front-components/:id layer │ → raw .mjs (no bundling) │ └─ Worker (browser) ├─ Fetch component .mjs ├─ Rewrite imports → blob URLs └─ import() rewritten source ``` ## Next PR - Estimate perf improvement by implementing a redis caching for front component client storage ( we don't even cache front comp initially ) - Implem frontent blob invalidation sse event from server --------- Co-authored-by: Charles Bochet <charlesBochet@users.noreply.github.com>	2026-03-24 18:10:25 +00:00