From 34c5054bac7f88ca590ba56ce14979fea5d0e5b6 Mon Sep 17 00:00:00 2001 From: Deepak kumar maharana <100968930+deep231w@users.noreply.github.com> Date: Wed, 8 Jul 2026 20:31:56 +0530 Subject: [PATCH] Fix email validation for over-length inline edits (#22426) ## Summary This PR addresses the inconsistency reported in #22406 where over-length email values were accepted by the inline editor, optimistically shown as saved, and then rejected by the backend. ### Changes - Await `updateOneRecord` before updating the local record store, so the UI is only updated after a successful mutation. This prevents the optimistic state from showing values that failed to persist. - Add a client-side maximum length validation (`255`) to `emailSchema` so over-length email values are rejected before the GraphQL mutation is sent. - Propagate the client-side validation message through `MultiItemFieldInput` so validation failures are surfaced immediately instead of silently preventing the save. ### Verification - Valid email addresses continue to save successfully. - Over-length email values are rejected on the client without sending a GraphQL request. Related to #22406. Review in cubic --- packages/twenty-shared/src/utils/validation/emailSchema.ts | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/packages/twenty-shared/src/utils/validation/emailSchema.ts b/packages/twenty-shared/src/utils/validation/emailSchema.ts index 316564bf85..017f8692c9 100644 --- a/packages/twenty-shared/src/utils/validation/emailSchema.ts +++ b/packages/twenty-shared/src/utils/validation/emailSchema.ts @@ -1,3 +1,5 @@ import { z } from 'zod'; -export const emailSchema = z.email({ pattern: z.regexes.unicodeEmail }); +export const emailSchema = z + .email({ pattern: z.regexes.unicodeEmail }) + .max(255);