I used the image squidex/squidex:dev with caching__replicated__enable: "true" and recorded a log from first a successful Request with Postman to /api/content/<<myapp>>/slideshow (appname “obfuscated”) and after that (in the end) a 404 request with Postman (same endpoint).
There is only one relevant log entry:
The interesting information:
There seems to be a side effect in combination with the setup container. This means If I do not start the setup container the 404 problem does not occur anymore.
What am I doing in the setup container:
I setup app, schema, via the Squidex Rest Api with the oauth client (with the credentials defined in identity:adminClientId, identity:adminClientSecret).
Basically currently it does the following:
Health Check (GET /healthz)
Aquire-AccessToken, after squidex healthy (POST /identity-server/connect/token)
Get-Available-Apps (GET /api/apps) (returns currently an empty set)
Create-App if not exists (POST /api/apps) => results in a crash because the app already exists => restart Setup Container and start with 1.
The setup container ran fine for some days, now it restarts in a loop due to the 404 problem.
I still do not understand it. Can you make this container available or the code…I need something I can reproduce. I guess you never delete the app in the container.
It contains a docker-compose with volumes. You need to add a Dns name mapping in your etc/hosts file for : marketing-cms -> 127.0.0.1 . It can be started via docker-compose up -d. Passwords are in the compose file. I tested with a GET request on https://marketing-cms/api/content/<<myadpp>>/slideshow
It just works for me. What I tried is to create a new app with your powershell script and then access it with a anonymous client over postman and it just works.
Did you try it with the mongo db volume? As I said for several days it worked for me too, but then I ran in this state, which is only reproducible if you use the mongo-db volume.
In the download, I send to you was a docker-compose file with a volumes folder. When you start the compose via docker-compose up Squidex, MongoDb starts with the versions defined in this docker-compose and with the volume from the volumes folder also defined there.
Maybe a permission problem, sorry I have worked on windows with these files, if you have linux/mac you will need to chown the mongo-db folder to the correct user/group.
It works with the linux subsystem for Windows. I had to change my docker.
I have found 2 issues:
Don’t trust the GetApps if you are an admin user or admin client, because of performance reasons there are some cases where I do not show all the apps (imaging I would have to provide all the apps for the cloud).
You can fix it for now by making a fix in the DB. If you to the collection States_Index_AppsByUser you will see an entry for your app client (“admin”) which has an ID to the old app, but not to the new one. It is a bug that the old is still there but it does not really matter. If you replace it with the id of the new app your script should work.
BUT: I have no idea what it has to do with the cache.
Thanks for your analysis, that sounds interesting.
No problem. The setup container is only for local development against the Squidex Api, in order to set up the cms with the same infrastructure as online. I can use GET /app/<<myapp>> directly to check whether the specified app already exists.
Good catch!
Yes, really interesting, why does it not happen without cache?
Can you also reproduce the correlation of refreshing the Squidex UI in the Browser and the Response status in Postmen?
In my opinion, it seems to be related to the caching on the one hand and to the authentication on the other hand, because I believe you return 404 if the authentication of the request fails?! Maybe it would be interesting whether this also happens with an authenticated client.
I can confirm with dev-550 fixes the issue for the anonymous client, even with the corrupt mongo-db state.
I tested also the Archive App -> Import App workflow and did not find any problems anymore.
One last question: I still have the problem that the admin client gets 404 for the “Get an app by name” /api/app/<<myapp>> request. I already copied the id of the new (not archived) app into States_Index_AppsByUser for the admin client and restarted docker-compose. I think the problem is now, that the new App is not “created-by” the admin client and that’s why I get 404. Is this correct and can I fix this anyhow?