Unable to Create New Fields After Renaming to a Previously Disabled Field Name
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!
9 Replies
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 ?Thanks for the reply @prastoin . We indeed have some rows with
NULL appliedAt values (here is the .csv with the null appliedAt migrations).
Query:
The version is 0.60.7-rcOk 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.0GitHub
Refactor migration runner within transaction (#12941) · twentyhq/t...
Modifying the data-model can sometimes fail in the middle of your
operation, due to the way we handle both metadata update and schema
migration separately, a field can be created while the associat...
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 everythingThanks 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?
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
Thanks a lot! We will follow the steps and your recommendation ❤️
No worries !
Some complementary information:
I might have drawn conclusions quite quickly
After step 4, we are now unable to create or update any new custom fields.Could you please share what error you're getting exactly please ? Also double checked and indeed even after fixing your instance you won't be able to create a field named as a deactivated one as it's technically not deleted from the api ( until hard deletion ) You would need to delete the field as follows:
