Upgrade error 0.3.2 > 0.3.3 : duplicate key value violates unique constraint
duplicate key value violates unique constraint "IndexOnNamePluralAndWorkspaceIdUnique"
reports healthy but:
fails with:
I tried deleting in "metadata"."objectData" to see if it had any effect but it did not:
115 Replies
Hi @🅹🅰🆈🅱🅴🅴 do you have data in your workspace? If yes you should not delete things from metadata
We have introduced the notion of "standard-ids" recently, I think you are missing it
test server so it is not an issue
ok!
do you see a standard-id column in your field metadata table?
If yes, you should run first: yarn command:prod workspace:add-standard-id
(Note that we are on 0.10.0, I can help you migrate directly to this version if you want)
That might be beneficial yes. Lets see if I can push it to test. I know there was changes with server/frontend not sure if I managed to fix those yet
have you added some code on your side?
or you are using twenty public images?
Using twenty public but the docker compose and nginx config needs some love. You merged the images and I havent had a chance to test the changes that was needed. I'll ping back here when It's up and running.
ok!
it should be easier than before
the postgres database is still separated so you should be able to connect it to the new twenty instance
Most likely tomorrow though, time for dinner and family! 🙂
Bon appetit!
Ping me if/when you need help
I'm now getting an error when I try and run migrate:prod in v0.10.0 so I believe it to be functioning.
I can't login but I assume that's because of database migrations not finishing attaching output of yarn database:migrate:prod
\d "core"."user":
@charles "ping" 🙂
mmh, there is an issue with migrations. What do you have in your core._typeorm_migrations table?
I think there is a mistake in our migration. I can fix it on main and push a patch to v0.10 but it wont help you right now. I think it's in 1711557405330-addMissingMigration line 39. What you can do is to manually add this constraint to your user table so the migration run
actually, it looks legit in Twenty codebase, I don't get why you were missing this constraint
nevermind, let's fix it on your workspace
I added the the FK and ran migration again and it worked
ok, perfect!
now, make sure to run yarn command:prod workspace:add-standard-id
then:
- yarn command:prod workspace:health -w {your_workspace_id} -d
And send the /logs folder content here, it will tell us how far your workspace postgres schema is from being ready for 0.10
Weird issue with mergin old and new logs. Last file should be correct
Ok! not too bad!
we need to migrate the timestamps format
https://discord.com/channels/1130383047699738754/1130383048173682821/1225854615883354133
Follow the step 2. to perform the timestamp migration
COLUMN_DEFAULT_VALUE_NOT_VALID and COLUMN_NULLABILITY_CONFLICT are the only two types of errors left from what I can see
ok!
yarn command:prod workspace:health -w {workspaceId} --fix default-value
yarn command:prod workspace:health -w {workspaceId} --fix nullable
mmh, that's bad, it should be handled
give me 1 sec
could you share your metadata.fieldMetadata table?
Weird formatting
it seems to be an issue with a composite field (CURRENCY, LINK, FULL_NAME)
I'm trying to reproduce locally
the fix command does not seem to work anymore
I'm investigating it
https://github.com/twentyhq/twenty/pull/5144/files
I'm publishing the new images with the fix
Ongoing push to dockerhub 🙂
it will be v0.10.1
it's there, let's try again when you have time
I can't see it? https://hub.docker.com/r/twentycrm/twenty/tags says it's updated but I can't see the image
sorry, it's not there yet actually, the amd build is still ongoing
GitHub
Release Twenty · twentyhq/twenty@b3e1d6b
Building a modern alternative to Salesforce, powered by the community. - Release Twenty · twentyhq/twenty@b3e1d6b
that's not this one!
🙂
I see
this one is to create the tag but it's failing, I've created the tag manually for now
It's out 🙂
Fixed 2/2 issues
But when I run the check afterwards with -d "Workspace is not healthy, found 2 issues"
when I run it over and over again without -d
I guess I can correct those manually
looks good!
could you share your fieldMetadata table again so I can double check?
(just to make sure we understood eachother - it thinks it fixes the issues but if I run it again it finds the same issues and thinks it fixes them again)
do not worry about the two remaining issues
they won't impact you for now
looks great!
okay, no that you workspace is healthy, except these too, we will sync it to the latest version (this will update standard fields and objects)
yarn command:prod workspace:sync-metadata -w {workspaceId} -f
-f is a flag to bypass health-check
I'm starting to believe I'm cursed!
haha, you are not cursed this sync logic is very complex and we still have a few things to figure out 😄
ok, look for pipelineStep field in your fieldMetadata and just delete it
These two?
yes, pipelineStep is completely deprecated
fk constraint from "relationMetadata"
it should be deleted but the sync script is failing to do it, so let's do it manually
please also remove the corresponding relationMetadata
I'm trying to reproduce the issue locally
These two I assume
yes!
same with pipelineStepId?
I assumed yes and soldiered on and ran into
so I reset back to before deleting pipelineStepId
yes you can delete pipelineStepId too
ok, we are close to the end, you are facing issues tied to the latest versions :p
does 22426d48-9f33-4f08-8039-14d409186aab correspond to the event object in objectMetadata?
It appears not
this one does not look good 😦 I'm unsure what the root cause is
Investigating it
It seems to be related to the issues I began with - upgrading from 0.3.2 to 0.3.3 if you look at first post in this thread
I can reproduce locally
wonderful
Btw I now also have a third issue in my workspace
you can delete this field too
ok, I've found the issue, there is a bug in the code 😦
Wonderful! Time well spent then instead of wasting time on a single user you can help all of them!
yes! Future updates will be easier, we are putting some process in place to check smooth upgrades
Okay, I'm preparing a bug fix
https://github.com/twentyhq/twenty/pull/5154/files
ongoing deploy to dockerhub
Will have to check it tomorrow. Dinner & family time again!
ok! have a good night
it's out, ping me tomorrow :p
@charles I now reach 0 issues workspace is healthy.
I ran
to correct nullability issues
Although oppurtunities still seem broken:
Great!
Ok are the other pages working?
Yes I realized I had screwed up the delete of pipelinestep, checking what happens when I do that correctly
Pipeline step are not used anymore you can get rid of them. I think the issue is with your views
dc0937e6-4ec5-438b-9b35-c767633a5bac 2024-04-24 14:16:49.906 2024-04-24 14:16:49.906 false 0.0 IconBuildingSkyscraper INDEX table 929b2053-8bf5-4122-80bf-1cf40e8d73d6 All Companies
e91f2452-f4fa-43c6-afae-1b7e82933a01 2024-04-24 14:16:49.906 2024-04-24 14:16:49.906 false 0.0 IconUser INDEX table 3988a475-f6ce-4b58-936a-aca8b5347696 All People
810ac59e-e704-434a-9c92-861feb62d7a3 2024-04-24 14:16:49.906 2024-04-24 14:16:49.906 false 0.0 IconTargetArrow INDEX table dce192b4-a33d-467b-a998-d3b3327b90fc All Opportunities
178327cf-7f9a-474d-8889-3a8c209250a8 2024-04-24 14:16:49.906 2024-04-24 14:16:49.906 false 1.0 40b87690-b1bf-42f1-9efa-11fae55cde62 IconLayoutKanban kanban dce192b4-a33d-467b-a998-d3b3327b90fc By Stage
Here are the views you should have in your workspace schema views table
INDEX view is the default table view, you should have one for each object
then for opportunities we also have a Kanban view (but you can create it manually from the View Picker UI)
maybe it's not your problem though, do you see any error on the server when you load the Opportunity page?When i delete them "correctly" the app stops working and I only get error:
ok!
it means you have a field of type RELATION without a relation tied to it
what is the fieldMetadata with id: fc6e52e9-6368-496c-91a0-833c89955e0c ?
I think you have only deleted one side of the relation (a relation is currently: a relationMetadata + 1 field RELATION on one side + 1 field RELATION on the other side + 1 field UUID on the other side)
these 4 entities come together
(this is being refactored to be simplified btw but now it works like this)
ok you should delete this field too
is 691b95a6-66a7-4ee4-a688-ad36b8afba48 the pipelineStep object?
If yes, let's delete it too
deleting fc.. and
With the app-error persisting. Should I sync metadata?
This still remains:
deleting as well
Now it loads the page but no data - still the same fc.. error
the other pipelinestep is for the dev workspace (you can completely remove this workspace btw)
what does fc stands for?
fc6e52e9-6368-496c-91a0-833c89955e0c
oh sorry
ok, so we have a schema cache mechanism
please bump the version in metadata.workspaceCacheVersion
Done
sneaky to have version as varchar!
good point 🙂
ok, is it working now?
Sadly not
Or wait. Yes
I was able to create new views
but the locked one is still broken. Can I get rid of the locked one?
no error messages regarding fc6.. anymore though so it might be something else that's preventing the view from being shown?
This is the only error I can see from client perspective
If I reload the page server logs show:
could you delete the new ones and share your workspace view and viewField tables?
it actually gets the correct amount of rows from opportunity though. Just fails to show them
"5" in this case
okay, make the INDEX All opportunities view a 'table' instead of a 'kanban' in the db!
(when you have a kanban view, you need to specifiy the kanbanFieldMetadataId too)
Can I change the default view to be kanban again or should I leave it as table?
(can just create a kanban view I guess?)
leave it as a table and you can create a kanban view (which should not be INDEX)
INDEX view are meant to be used as a default views to show related records from the show page of a specific record, we want it to always be a table
Not sure when it appeared but now I have a
Is this an issue?
I'm running version v0.10.2 but it reports as 0.4.0
image running: twentycrm/twenty:v0.10.2
This might just be an issue with your v0.10.x release though
interesting :p
that's OK, it's a false positive we have!
In addition all tasks have lost the relations
Or rather it seems to not load it correctly
If I check tasks -> select person assigned it loads without any relations. But if I go into the opportunity first so it loads tasks that way they are filled in with which opportunity they are connected
I know I saw 0.10.0 before upgrading to 0.10.1 or 0.10.2
I'll patch that in v0.10.3 tomorrow
Is this a known issue or something wrong with my migration/upgrade?
Couldnt find any in github when I looked atleast
I can reproduce it on my environment. It's a bug that has been recently introduced, we will patch it tomorrow
not related to your setup 🙂
Excellent
This was a bit painful 😄 but a lot of learnings
thanks for going through this
Our sales team is extremely happy with the application as of now so any kind of migration issue is just meh as compared to the clunkyness of all other crm options we have tried
It should only get better 🙂
I'll ping you once the Tasks bug is fixed
Clunkyness of migration ends up in IT team which happens to like troubleshooting so yay me I guess
I'm releasing v0.10.4 with the Task fix 🙂
Ah that looks better!
👍
I am getting logged out somewhat quickly though with (10-30 minutes maybe, havent tested exactly):
In the log. Unclear if it's an issue in my configuration or something more general
Is it possible to turn on more verbose logging?
yes we have issue with the refreshToken
you can set your ACCESS_TOKEN_EXPIRE_IN to a longer time
I have tried to codify all the steps we took to be able to replicate it on live but either I missed something or something is still not right:
getting
Should this be deleted as well?
(I assume 0.10.6 does not fix it but I'm testing that right now instead of 0.10.4)
It actually did fix it should have waited before speaking
yes, I have been troubleshooting with @iero too and added fixes to v0.10.6
next upgrades will be way smoother I promise
Thank you for running ahead of me @iero !
I have the same problem in 0.10.6. I setup a '1d' limit for ACCESS_TOKEN_EXPIRE_IN but same thing
we use 7d on the cloud for now FYI, it should not cause too much issue
the best practice is to have something like ~30min and to leverage the refresh token, we are working on it too
regarding the error above, is it another workspace on on the same? I thought your workspace was fully functional when we worked on it?
If you want, we can schedule a voice session to fix your issue on Monday
Unknown User•7mo ago
Message Not Public
Sign In & Join Server To View
I forced those (default) parameters in docker-compose.yaml:
Restarted using
docker-compose up --build -d
So far it seems to work.
I have to refresh the page but I stay connected