upgraded to 1.7 from 1.6.7 is stuck with 1.6.7 db version
I have just upgraded to 1.7 from 1.6.7. Since then, the application thinks it is v1.7.7 and the db thinks it is 1.6.7.
I then tried running: yarn database:migrate:prod
But it says:
query: SELECT * FROM current_schema()
query: CREATE EXTENSION IF NOT EXISTS "uuid-ossp"
query: SELECT version();
query: SELECT * FROM "information_schema"."tables" WHERE "table_schema" = 'core' AND "table_name" = '_typeorm_migrations'
query: SELECT * FROM "core"."_typeorm_migrations" "_typeorm_migrations" ORDER BY "id" DESC
No migrations are pending
How do I fix this? Is this a known problem?37 Replies
I thought app version and db version should be the same?
I am able to log into the twenty app. And admin panel reports this:
Not sure if this is just OK. In that case I will just ignore...
And continue to upgrade to 1.8
I would expect their to be migrations after the upgrade and that those migrations should cause the db version to be bumped.
This does not seem to have happened. I am now unsure how to proceed.
@EbenezerIbiza : I have the same issue. At my end, Twenty works fine with 1.7.7 even when database version says 1.6.7, but when I try to upgrade to 1.8 everything breaks...
Hello please twenty-server logs during the upgrade
Should be an error along upgrade
docker logs twenty-server-1|grep error
[Nest] 58 - 10/22/2025, 4:38:32 PM ERROR [WorkspaceSyncMetadataService] Sync of standard objects failed with:
[Nest] 58 - 10/22/2025, 4:38:32 PM ERROR [WorkspaceSyncMetadataService] EntityPropertyNotFoundError: Property "createHandoffFromDefaultAgent" was not found in "AgentEntity". Make sure your query is correct.
[Nest] 58 - 10/22/2025, 4:38:33 PM ERROR [UpgradeCommand] Error in workspace 14ca1cd3-a445-4ebd-a985-2566afc938b5: Property "createHandoffFromDefaultAgent" was not found in "AgentEntity". Make sure your query is correct.
[Nest] 58 - 10/22/2025, 4:38:33 PM ERROR [UpgradeCommand] undefined
This is from 1.6.7 to 1.7.7 (using tag 1.7 in .env file)
Downgrading from 1.7.7 to 1.6.7 works fine, no errors. Upgrading again to 1.7.7 gives same errors as above again.
Cool thanks ! That's what we were looking for
Will investigate further tomorrow
Just FYI: Incremental upgrade 1.6.7->1.7.1->1.7.3->1.7.6->1.7.7 gave no errors.
Incremental upgrade 1.7.7->1.8.1 then gave this:
error: error: invalid input value for enum workspace_18b3onizg22d9k57g0kh2azlh."messageChannel_syncStage_enum": "MESSAGE_LIST_FETCH_PENDING"
error: error: invalid input value for enum workspace_18b3onizg22d9k57g0kh2azlh."calendarChannel_syncStage_enum": "CALENDAR_EVENT_LIST_FETCH_PENDING"
Incremental upgrade to 1.8.2 then gives no errors.
After this, twenty works fine - but database version is at 1.8.1 and not 1.8.2 as expected.
That's not an issue, from the moment it's in 1.8 we're good
What was the context of this error ? was it the upgrade command ?
I guess so - this was the output of:
docker logs twenty-server-1|grep error
right after changing tag from 1.7.7. to 1.8.1 in the .env file and then running
docker compose up --build --force-recreate -d
No errors popped up during the incremental upgrade until that using the same procedure.
I have a bunch of 'Uncompiled mssage detected!' errors telling me to please compile my catalog first for ICU features to work properly, but apart from that everything seems to work fine.
Not blocking
The translations are added dynamically through periodical PR from a cicd scanning for new translations key that haven't been translated yet in the catalog
Some version of twenty might have missing translations, should never result in any runtime issue but you might find weird non translated translation keys in the UI in specific locale
Thanks, not really concerned about that, they seem mostly harmless and they've been there before as well without any runtime issues.
I am not sure how to proceed on my end?
Should I provide any kind of logs, etc?
Please try to incrementally upgrade starting from 1.6
If your workspace version does not get updated to 1.7 you should find and share an error in your twenty-server logs
@El Odve I'm not sure to understand how you've fixed the
createHandoffFromDefaultAgent, have you updated your workspace version in database manually ?from 1.6? But I already upgraded to 1.7? It is just the db that is tuck on 1.6
It is unclear to me how to proceed
I fear breaking things further
More information here https://discord.com/channels/1130383047699738754/1372831640920789032/1372833279610196039
If a workspace version is not equal to the previous version than the upgrade is ignored and you need to downgrade to the corresponding version that can handle the upgrade
Hmm... The link does not seem to work. How do I downgrade?
@prastoin: createHandOffFromDefaultAgent got automagically fixed by updating from 1.8.1 to 1.8.2 š¤·
I had similar issues. I was on 1.7.x running fine, though experiencing some known bugs. Upon a naive upgrade to 1.8.2, I see those errors reported. I had taken a backup at that upgrade point, so rolled my DB, volumes etc back to the 1.7.x state.
I then downgraded to v1.6 (i.e. docker compose down, tag to 1.6, up using sudo docker-compose up --build --force-recreate), then to 1.7.2, then to 1.7.3 then to 1.7.6 (skipping 1.7.7) then to 1.8.2.
On the final step to 1.8.2, it errored on the first attempt. I simply started the container again, and had successful migration - unsure if this is okay but it appears happy and migrated now running on v1.8.2.
This was on my dev instance - going to take a backup and attempt this on my production instance now.
@prastoin is there a reason these issues are happening (having PTSD flashbacks to 0.38.x era issues which caused me major headaches) - this is super scary for production. Why are test cases in the Twenty open source project not catching these migration problems pre-release? I feel like a guinea pig whenever I run a migration!
Can confirm I got this to work again - but this time I had to retry the
sudo docker-compose up --build --force-recreate three times before it succeededHey @ParallelPlatypus, glad to see that you've been able to upgrade your instance in the end
Totally agreed, when upgrading your twenty instance therer're two steps:
- Workspace agnostical migration -> This is the the shared schema database definition. This is run prior of below step ( core schema )
- Workspace scope upgrade -> Here will be handled everything related to a given workspace. When finished the given workspace version got upgraded in database ( workspace_whatever )
Please note that by the end of the year at the latest, this complexity will be totally handled under the hood by the v2 engine
A given twenty instance will have grain over a range of twenty version upgrade and migration. ( unless a breaking change is introduced in the upgrade process at least this will be documented )
In a nutshell incremental twenty instance will be handled by twenty directly. This does not mean that an upgrade won't fail anymore but devxp will be enhanced with meaningfull logs and no more instance corruption
@Prastoin may I ask how I should proceed from where I stand here? Do I need to downgrade somehow? I cannot find docs on that.
Please downgrade to the instance your workspace is blocked at
Try upgrading to the next and share any error in twenty-server logs
Where do I find the instructions on how to downgrade?
Do I just change the TAG in .env and restart containers?
Yes exactly, please refer to above messages
Thanks
I downgraded to 1.6.7. When I grep -i "error" in twenty-server logs, I dont get any hits.
The error should occurs when upgrading in 1.7
So I want to upgarde to 1.7 again now?
Yes
Please proceed to
@prastoin how to proceed from here?<
š
@EbenezerIbiza: did you run incremental upgrades from 1.6.7 or did you put in 1.7 straight away?
I just adjust the TAG value in .env. I set it to 1.6 on 9/22. Then on 10/21, I set it to 1.7.
I always only set the first two numbers. Is that a problem?
What worked for me was incremental upgrades from 1.6.7, i.e. 1.6.7->1.7.2->1.7.3->1.7.6->1.7.7->1.8.1->1.8.2
It's not supposed to make a difference, but it did. Must be some minor changes in one or more incremental upgrades that is skipped when using just the 1.7 tag, which will (in this case) upgrade directly from 1.6.7->1.7.7
So change the tag, upgrade, change the tag, upgrade, rinse and repeat until you're on 1.8.2...
Best of luck!
I had the same problem from 1.2 to 1.3.
Hi, I am stuck on v1.7.7 (Self Hosting on Docker)
I've upgraded to v1.8 this is the error I see across the DB, Server and worker containers
2025-11-05 14:17:07.764 UTC [121] ERROR: column Workspace.trashRetentionDays does not exist at character 490
I have attempted to do what El Odve suggested by 1.7.7->1.8.1->1.8.2 but I ended up with the same issue.
Any help would be greatly appreciated.
Thanks