What I did is that I reconfigured my squidex container to force the docker image version to 4.5.1; then I restarted it: then I restored my last backup before the issue to a new app.
On this restored app, everything is working fine : images are back in place, content history is shown again.
So I presume there is a hitch between Squidex 5.0.0 db schema and 4.5.1 db schema.
Could you confirm this please?
I am not sure, what goes wrong. But 5.0.0 is still in beta, so I don’t know what is wrong. But the Beta does not make any changes to the mongodb connection itself.
here is complete log archive
https://mega.nz/file/1RdCHY5Q#SDpf1ygNoPgPKIUgHDwoZ-Qj6NEssldGURDXTnxRVos
Thanks, do you one or multiple nodes? I do not see any error after the migration was running that was introduced with 5.0
Edit: I do not see any error at all in the logs.
only one node is running
there are MongoDB.Driver.MongoConnectionException in the xxx.23…log file
the upgrade occured on 2020-09-02 03:18:32 (see 2020_09_02_RD0050F2817953_docker.log )
first exception occured on 2020-09-02 10:20:44 (see 2020_09_02_RD0050F2817953_default_docker.42.log) : Microsoft.Azure.Storage.StorageException
then on 2020-09-02 10h37 there is Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException
then on 2020-09-02 13:26 there is MongoDB.Driver.MongoConnectionException (see 2020_09_02_RD0050F2817953_default_docker.23.log )
Thank you. The stack trace has nothing to do with the changes I did. Not sure, why it happened.
But as I said: The 5.0.0 is still in beta, but the problem with references might be interesting, I will have a look to that.
ok, thank you for your invetigation.
I have the same issue after the upgrade it was used the last beta (because beta is published as “latest” in docker hub). And I will break all reference to assets. And same as Greg after downgrade to 4.6 (using specific version in docker-compose file) I cannot access most of the part my app. I think it will be better to replace the latest version in dockerhub with 4.6 and use a different tag for beta version. Because I do not expect this and as I found here I am not only one.
But something positive restore with build-in backup is pretty nice.
Yes, the problem with latest ist stupid.
Hi
I’m experiencing the same issue - and I try to figure out how to fix this. My backup is too old, and creating a new backup on the version 5 beta (which has content there, but broken references) fails. I cannot reference assets to fix it manually either. Both just assigning assets or creating a new app and assigning assets doesn’t work.
Do I have any other options than to build the app manually on version 4.6 by copy pasting, @Sebastian ?
You can try dev-4827 and see if it fixes the problem for you.
1 Like
Thanks, it works!
I also needed to troubleshoot a “HPE_HEADER_OVERFLOW” I got for my big graphql query, but found the solution: 502 Bad Gateway on some graphql queries
1 Like
@Sebastian do you have any tips in how to upgrade to the latest version? I backed up our MongoDB file share just in case, and tried to upgrade from dev-4827 to 5.2.1 - but that resulted in assets not showing and all but 2 schemas not showing. When reverting to dev-4827, it seems both assets and schemas still works as expected.
E.g. if there is a version in between the two that could work out as a transition version?
There is no version in between. You can send me your backup and I can have a look, but it should just work. Perhaps the migration was not running in your case?
Sure, I can send a backup for one of the apps. However, we have 4 apps and one of the apps started to fail creating backups after the miss upgrade when we went for the dev beta 5 latest version:
But I guess that is another issue.
The backup does not help that much, I need a full backup of your database with mongo backup, otherwise I would create a totally different environment.
The migration was not running properly. I don’t know why. If you connect to your mongo database, you see a collection Migration with one document. Change version to 21 and restart Squidex. Then check if the number of documents in Events2 collection match to the number of documents in Events
1 Like
Thanks again! We now have it working on 5.2.1 - with Events2 matches the document count in Events.