twenty

vynte-infra/twenty

Fork 0

...

Author	SHA1	Message	Date
Sonarly Claude Code	ec12597a1f	ConsoleListener.release() accumulates wrapper chain causing stack overflow https://sonarly.com/issue/5485?type=bug Each logic function execution adds an extra wrapper layer to global console methods via ConsoleListener.release(), eventually exceeding V8's call stack limit after thousands of executions. Fix: The `release()` method in `ConsoleListener` was creating a new arrow function wrapper around the captured original console method instead of directly restoring it. Each call to `release()` added one more layer to an ever-growing call chain, eventually causing a stack overflow after thousands of logic function executions. The fix replaces the wrapper creation with a direct assignment: ```typescript file=packages/twenty-server/src/engine/core-modules/logic-function/logic-function-drivers/utils/intercept-console.ts lines=26-31 release() { Object.keys(this.originalConsole).forEach((method) => { // @ts-expect-error legacy noImplicitAny console[method] = this.originalConsole[method]; }); } ``` Before: Each `release()` call did `console[method] = (...args) => { this.originalConsole[method](...args) }` — creating a new closure that held a reference to the previous wrapper, forming a chain N layers deep after N executions. After: Each `release()` call does `console[method] = this.originalConsole[method]` — directly restoring the reference captured at construction time, with no wrapper and no chain growth regardless of how many executions have occurred.	2026-03-04 01:31:35 +00:00
Sonarly Claude Code	970d8511e1	Microsoft 404 on folder delta endpoint permanently fails email sync https://sonarly.com/issue/8521?type=bug When Microsoft Graph API returns HTTP 404 during message list fetch (e.g., deleted folder), the exception handler permanently marks the message channel as FAILED_UNKNOWN instead of retrying, breaking email sync for the affected user. Fix: ## Fix The `handleNotFoundException` method was permanently failing the message channel (`FAILED_UNKNOWN`) when a `NOT_FOUND` exception occurred during `MESSAGE_LIST_FETCH`. This was incorrect because Microsoft Graph API legitimately returns HTTP 404 for its folder delta endpoint when a mail folder is deleted, moved, or otherwise inaccessible — which the Microsoft driver maps to `MessageImportDriverExceptionCode.NOT_FOUND`. The fix removes the special-case branch that treated `NOT_FOUND` during `MESSAGE_LIST_FETCH` as an impossible/fatal state, and instead routes all `NOT_FOUND` exceptions (regardless of sync step) to the retry path: `resetAndMarkAsMessagesListFetchPending`. This is consistent with: - How `SYNC_CURSOR_ERROR` is handled (also resets and retries) - The original intent before the Oct 2025 refactor (commit `cd4800eb86d`) introduced the permanent failure path ```typescript file=packages/twenty-server/src/modules/messaging/message-import-manager/services/messaging-import-exception-handler.service.ts lines=247-256 private async handleNotFoundException( syncStep: MessageImportSyncStep, messageChannel: Pick<MessageChannelWorkspaceEntity, 'id'>, workspaceId: string, ): Promise<void> { await this.messageChannelSyncStatusService.resetAndMarkAsMessagesListFetchPending( [messageChannel.id], workspaceId, ); } ``` The old code for `MESSAGE_LIST_FETCH` (which created a "should never happen" Sentry error and called `markAsFailed`) is entirely removed. When the delta link becomes invalid (folder deleted/moved), the sync cursor resets and the channel queues for a fresh list fetch rather than being permanently broken.	2026-03-04 01:25:20 +00:00

Author

SHA1

Message

Date

Sonarly Claude Code

ec12597a1f

ConsoleListener.release() accumulates wrapper chain causing stack overflow

https://sonarly.com/issue/5485?type=bug

Each logic function execution adds an extra wrapper layer to global console methods via ConsoleListener.release(), eventually exceeding V8's call stack limit after thousands of executions.

Fix: The `release()` method in `ConsoleListener` was creating a new arrow function wrapper around the captured original console method instead of directly restoring it. Each call to `release()` added one more layer to an ever-growing call chain, eventually causing a stack overflow after thousands of logic function executions.

The fix replaces the wrapper creation with a direct assignment:

```typescript file=packages/twenty-server/src/engine/core-modules/logic-function/logic-function-drivers/utils/intercept-console.ts lines=26-31
release() {
    Object.keys(this.originalConsole).forEach((method) => {
      // @ts-expect-error legacy noImplicitAny
      console[method] = this.originalConsole[method];
    });
  }
```

**Before:** Each `release()` call did `console[method] = (...args) => { this.originalConsole[method](...args) }` — creating a new closure that held a reference to the previous wrapper, forming a chain N layers deep after N executions.

**After:** Each `release()` call does `console[method] = this.originalConsole[method]` — directly restoring the reference captured at construction time, with no wrapper and no chain growth regardless of how many executions have occurred.

2026-03-04 01:31:35 +00:00

Sonarly Claude Code

970d8511e1

Microsoft 404 on folder delta endpoint permanently fails email sync

https://sonarly.com/issue/8521?type=bug

When Microsoft Graph API returns HTTP 404 during message list fetch (e.g., deleted folder), the exception handler permanently marks the message channel as FAILED_UNKNOWN instead of retrying, breaking email sync for the affected user.

Fix: ## Fix

The `handleNotFoundException` method was permanently failing the message channel (`FAILED_UNKNOWN`) when a `NOT_FOUND` exception occurred during `MESSAGE_LIST_FETCH`. This was incorrect because Microsoft Graph API legitimately returns HTTP 404 for its folder delta endpoint when a mail folder is deleted, moved, or otherwise inaccessible — which the Microsoft driver maps to `MessageImportDriverExceptionCode.NOT_FOUND`.

The fix removes the special-case branch that treated `NOT_FOUND` during `MESSAGE_LIST_FETCH` as an impossible/fatal state, and instead routes all `NOT_FOUND` exceptions (regardless of sync step) to the retry path: `resetAndMarkAsMessagesListFetchPending`. This is consistent with:
- How `SYNC_CURSOR_ERROR` is handled (also resets and retries)
- The original intent before the Oct 2025 refactor (commit `cd4800eb86d`) introduced the permanent failure path

```typescript file=packages/twenty-server/src/modules/messaging/message-import-manager/services/messaging-import-exception-handler.service.ts lines=247-256
private async handleNotFoundException(
    syncStep: MessageImportSyncStep,
    messageChannel: Pick<MessageChannelWorkspaceEntity, 'id'>,
    workspaceId: string,
  ): Promise<void> {
    await this.messageChannelSyncStatusService.resetAndMarkAsMessagesListFetchPending(
      [messageChannel.id],
      workspaceId,
    );
  }
```

The old code for `MESSAGE_LIST_FETCH` (which created a "should never happen" Sentry error and called `markAsFailed`) is entirely removed. When the delta link becomes invalid (folder deleted/moved), the sync cursor resets and the channel queues for a fresh list fetch rather than being permanently broken.

2026-03-04 01:25:20 +00:00

1 changed files with 1 additions and 5 deletions

									
										packages/twenty-server/src/engine/core-modules/logic-function/logic-function-drivers/utils/intercept-console.ts
									
		+1
		-5
	
												View File
												
				@@ -26,11 +26,7 @@ export class ConsoleListener {

				  release() {

				    Object.keys(this.originalConsole).forEach((method) => {

				      // @ts-expect-error legacy noImplicitAny

				      // eslint-disable-next-line @typescript-eslint/no-explicit-any

				      console[method] = (...args: any[]) => {

				        // @ts-expect-error legacy noImplicitAny

				        this.originalConsole[method](...args);

				      };

				      console[method] = this.originalConsole[method];

				    });

				  }

				}

Compare commits