twenty

Author	SHA1	Message	Date
Sonarly Claude Code	f893bfe273	Empty optimistic flat entity maps cause view field creation to fail https://sonarly.com/issue/4058?type=bug A bug in `setupOptimisticCache` in v1.18.1 causes the optimistic view field maps to be empty during the workspace migration build, causing all view field creation operations on existing views with existing fields to throw `BUILDER_INTERNAL_SERVER_ERROR`. Fix: No code changes needed — the fix is already in the codebase. The root cause was two bugs in v1.18.1 that were fixed in commit `af0af0a237` ("Fix cross app installation (#18151)"), merged 2026-02-23: 1. `setupOptimisticCache` bug (in `workspace-migration-build-orchestrator.service.ts`): The old code had `isDefined(allFlatEntityMaps[currFlatMaps])` in a guard clause that always evaluated to `true` because `createEmptyAllFlatEntityMaps()` creates non-null empty objects for every metadata type. This prevented the actual `fromToAllFlatEntityMaps.from` data from being applied, leaving the operated-on entity type's maps empty. Fix: Added an early-return path when `dependencyAllFlatEntityMaps` is defined, bypassing the broken reduce loop entirely. 2. Missing entity type in dependency maps (in `workspace-migration-validate-build-and-run-service.ts`): The old `computeAllRelatedFlatEntityMaps` computed `dependencyAllFlatEntityMaps` only from related metadata names (e.g., `view`, `fieldMetadata`, `objectMetadata`) but not the operated-on type itself (e.g., `viewField`). Fix: Changed to use `allMetadataNameCacheToCompute` which includes both the operated-on type and its related types, plus added application ID filtering via `getSubFlatEntityMapsByApplicationIdsOrThrow`. To resolve this Sentry error in production, deploy a release that includes commit `af0af0a237` or later.	2026-03-06 17:56:04 +00:00
Sonarly Claude Code	6b7f5de3a7	SendInvitations crashes when workspace member doesn't exist during onboarding https://sonarly.com/issue/4106?type=bug The sendInvitations resolver throws EntityNotFoundError because it assumes a workspace member always exists for authenticated users, but the JWT auth strategy deliberately skips workspace member validation during workspace creation states (PENDING_CREATION/ONGOING_CREATION). Fix: Added workspace activation status validation to both `sendInvitations` and `resendWorkspaceInvitation` methods in `workspace-invitation.resolver.ts`. Before attempting to look up the workspace member, the resolver now checks `isWorkspaceActiveOrSuspended(workspace)` and throws a `WorkspaceException` with code `WORKSPACE_NOT_READY` if the workspace is still in `PENDING_CREATION` or `ONGOING_CREATION` state. This prevents the `EntityNotFoundError` crash by failing fast with a meaningful, user-friendly error before the `findOneOrFail` query that assumes a workspace member exists. Also added the `WORKSPACE_NOT_READY` exception code and its user-friendly message to `workspace.exception.ts`, following the existing exhaustive switch pattern.	2026-03-06 17:53:18 +00:00
Sonarly Claude Code	629d524837	chore: additional changes for Google OAuth sign-up fails when profile picture do	2026-03-06 17:46:37 +00:00
Sonarly Claude Code	243734d29e	chore: improve monitoring for Google OAuth sign-up fails when profile picture do The Sentry error title was `"Failed to fetch image from URL: "` with an empty suffix because the original error's `.message` was an empty string. This made it impossible to determine the actual failure type (ECONNRESET, ETIMEDOUT, TLS error, etc.). Change in `image.ts`: When re-throwing the error in `getImageBufferFromUrl`, the code now falls back to the error's `.code` property (present on AxiosError and Node.js system errors like `ECONNRESET`, `ETIMEDOUT`, `ERR_NETWORK`) when `.message` is empty. This ensures Sentry and log messages always contain actionable diagnostic information instead of empty strings. Before: `Failed to fetch image from <url>: ` (empty — un-debuggable) After: `Failed to fetch image from <url>: ECONNRESET` (actionable)	2026-03-06 17:46:34 +00:00
Sonarly Claude Code	569951ba6b	Google OAuth sign-up fails when profile picture download encounters network error https://sonarly.com/issue/10350?type=bug A transient network failure fetching a Google profile picture during OAuth sign-up causes the entire workspace creation transaction to roll back, completely blocking new user registration. Fix: The original root cause fix (commit `4c001778c2`) addressed the v1.18.1 legacy code path by wrapping `uploadImageFromUrl` in a try/catch within `computeDefaultAvatarUrlLegacy`. The codebase has since been refactored to remove the legacy path and always use `computeDefaultAvatarUrlMigrated`. However, the migrated path has the same vulnerability: `uploadWorkspaceMemberProfilePictureFromUrl` is called without a try/catch at line 483-491 of `user-workspace.service.ts`. While the image fetch is internally protected by `fetchImageBufferFromUrl`'s try/catch, the subsequent file storage upload (`uploadCorePicture` → `fileStorageService.writeFile`) is not. A storage service failure after a successful image download would still crash the sign-up transaction. Change: Wrapped the `uploadWorkspaceMemberProfilePictureFromUrl` call in `computeDefaultAvatarUrlMigrated` with a try/catch that logs a warning and returns `undefined`, matching the pattern already used for the existing-user branch of the same method (lines 461-478) and the original v1.18.1 fix.	2026-03-06 17:46:34 +00:00

Compare commits

Diff Content Not Available