twenty

Author	SHA1	Message	Date
Sonarly Claude Code	6ec7a58f5e	BlockNote 0.31.1 Enter key crashes when splitting blocks near tables https://sonarly.com/issue/14499?type=bug BlockNote 0.31.1's Enter key handler throws an unhandled `TransformError: Cannot join blockGroup onto blockContainer` when splitting blocks in rich text fields containing table blocks, crashing the editor. Fix: No code changes needed. The bug is in BlockNote 0.31.1's internal Enter key handler (`Ou` function), which calls `Transaction.split(pos, 2)` and produces an invalid `ReplaceStep` when table blocks are present in the document. This is a third-party library bug. The fix was already merged by Abdullah (@mabdullahabaid) in commit `4ed09a3feb` ("Upgrade blocknote dependencies from 0.31.1 to 0.47.0", PR #18207, Feb 27 2026). This upgrade brings in 16 minor versions of BlockNote fixes including improvements to block splitting, table handling, and the Enter key handler. The bug persists in production only because v1.18.1 (released Feb 20) predates the upgrade. Deploying the next release will resolve this issue for all users.	2026-03-13 16:53:38 +00:00
Sonarly Claude Code	0c5caaa9e6	chore: additional changes for Missing messageChannel entity metadata during nest	2026-03-13 16:46:53 +00:00
Sonarly Claude Code	c5928610da	chore: improve monitoring for Missing messageChannel entity metadata during nest Monitoring: Prevent secondary errors from masking original errors in message import error handler The `handleUnknownException` method in `MessageImportExceptionHandlerService` captures the original exception to Sentry, then calls `markAsFailed()`. If `markAsFailed` throws (as in this bug), the secondary error propagates up and becomes the Sentry-reported error — masking the original cause. The Sentry event we investigated only showed the `EntityMetadataNotFoundError`, not the original message import failure. The fix: 1. Added a `Logger` instance to the service 2. Wrapped `markAsFailed` in a try-catch that logs BOTH the original error and the secondary error 3. The secondary error is captured separately to Sentry with workspace context This ensures: - The original error is always captured (already was) - If `markAsFailed` fails, the secondary error is captured with context linking it to the original - The log line includes both errors for correlation - The secondary error no longer masks or replaces the original error File: `packages/twenty-server/src/modules/messaging/message-import-manager/services/messaging-import-exception-handler.service.ts`	2026-03-13 16:46:50 +00:00
Sonarly Claude Code	af040b48a6	Missing messageChannel entity metadata during nested workspace context in error handler https://sonarly.com/issue/14490?type=bug Worker fails to mark a message channel as "failed" because the ORM entity metadata cache for the workspace doesn't include the `messageChannel` entity when loaded in a nested `executeInWorkspaceContext` call during error handling. Fix: Fix: Align `findMetadata` with TypeORM's string target resolution The `GlobalWorkspaceDataSource.findMetadata()` override used only strict reference equality (`metadata.target === target`) to match entity metadata. TypeORM's built-in `DataSource.getMetadata()` has additional fallback logic for string targets — it also checks `metadata.tableName` and `metadata.name`. The override was missing these fallbacks. When `target` is a string like `'messageChannel'` (as passed from `GlobalWorkspaceOrmManager.getRepository(workspaceId, 'messageChannel')`), and the cached `EntityMetadata.target` is set to the EntitySchema instance (not the string name), the strict `===` comparison fails. The fix adds the same fallback logic TypeORM uses: for string targets, also match against `metadata.tableName` and `metadata.name`. The existing `===` check is preserved as the first (fast-path) condition, so no existing behavior is broken. The string fallback only activates when the strict check fails. File: `packages/twenty-server/src/engine/twenty-orm/global-workspace-datasource/global-workspace-datasource.ts`	2026-03-13 16:46:49 +00:00

Compare commits

Diff Content Not Available