Unable to Create New Fields After Renaming to a Previously Disabled Field Name

[lone light]

Hey team,

Thanks for the great work on this project!

We've encountered an issue where creating new custom fields has stopped working, seemingly after a specific sequence of field renaming operations. We suspect this is related to reusing a previously disabled field name.

Steps to Reproduce:

01 - Created a custom field named 'startedFollowingAt' (text type).

02 - Disabled the 'startedFollowingAt' field.

03 - Created a new field named 'socialMediaStartedFollowingAt' (date type).

04 - Attempted to rename 'socialMediaStartedFollowingAt' to 'startedFollowingAt'. This operation failed with an error indicating the name was already in use, even though the original 'startedFollowingAt' was disabled.

Observed Behavior:

After step 4, we are now unable to create or update any new custom fields.

Additional Context:

We've tried clearing the Redis cache, but this did not resolve the issue.

We're unsure if the Redis cache clear contributed to the problem or if it's an independent factor.

Has anyone encountered a similar issue or have any insights on how to diagnose or resolve this? Any help would be greatly appreciated!

[covert lynx]

Hello there ! Thanks for the kind words

We've tried clearing the Redis cache, but this did not resolve the issue.
Regarding Q4 it does seem to be a cache issue 🤔, you've run the yarn command:prod cache:flush command isn't ?

Could you please share any rows with NULL appliedAt value at default database core schema workspaceMigration table ?

( be sure to filter by your workspace id in case you have multi workspace twenty instance )

Also what twenty version are you using exactly ?

[lone light]

Thanks for the reply @covert lynx . We indeed have some rows with NULL appliedAt values (here is the .csv with the null appliedAt migrations).

Query:

SELECT
    CAST(id AS TEXT) AS id,
    name,
    "isCustom",
    "appliedAt",
    CAST("workspaceId" AS TEXT) AS "workspaceId",
    "createdAt"
  FROM core."workspaceMigration"
  WHERE "appliedAt" IS NULL

The version is 0.60.7-rc

[covert lynx]

Ok flushing cache won't fix your issue

You've faced a metadata and schema race condition, where metadata -> lets say global parameters, has been migrated but not your workspace schema -> anything scoped to your workspace database architecture

There's no way to fix the issue if it's not manually

This bug should never re-occurr as fixed in https://github.com/twentyhq/twenty/commit/41becaaea46e3786a5363a3de1415ad942b23936
that should released this thursday PARIS TZ v1.1.0

Fixing manually:

• Remove NULL appliedAt workspace migrations rows
• Remove field ( startedFollowingAt from my understanding ) from core fieldMetadata
• Remove field column from your workspace_schema.YOUR_OBJECT_METADATA
• Flush cache
• From the ui re-craft everything

[lone light]

Thanks for helping us understanding the issue. You have no idea of how you are saving us here.

About the "From the ui re-craft everything" step, this is related only to the fields that have NULL appliedAt at the workspace migrations?

[covert lynx]

Thanks about that ! You're welcome ! Always happy to help !

About the "From the ui re-craft everything" step, this is related only to the fields that have NULL appliedAt at the workspace migrations?

Yes indeed, in the end only step Q4 that should not be working

When you've been able to stabilized your twenty instance I would recommend making a backup of you database so you can play with it without too many concerns

[lone light]

Thanks a lot! We will follow the steps and your recommendation ❤️