[SOLVED] Mysterious 404 (NotFound) issue

Ok, I have interesting test results.

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:

{
    "logLevel": "Warning",
    "message": "Cannot find app with the given name.",
    "appId": "404",
    "appName": "",
    "timestamp": "2021-02-02T11:37:33Z",
    "app": {
      "name": "Squidex",
      "version": "4.0.0.0",
      "sessionId": "90d8547a-ee10-495c-8fa2-a3f1c6fb312e"
    },
    "web": {
      "requestId": "00-2a5db701054f69438860b7ebab1cc4ae-580a9e19c59bd24f-00",
      "requestPath": "/content/<<myapp>>/slideshow",
      "requestMethod": "GET",
      "routeValues": {
        "area": "Api",
        "action": "GetContents",
        "controller": "Contents"
      }
    }
  }

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:

  1. Health Check (GET /healthz)
  2. Aquire-AccessToken, after squidex healthy (POST /identity-server/connect/token)
  3. Get-Available-Apps (GET /api/apps) (returns currently an empty set)
  4. 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.

Of course. Link has been removed…

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

Great. Btw: It is probably much easier if you write a simple c# program with the SDK :wink:

Next time …

You are right, found the Sdk after my setup script.
Are you able to reproduce using this setup?

Not yet, but I had other things to do as well.

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.

Not yet, which mongodb version do you use? If I do not have the exact version it does not start :frowning:

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.

Sorry, I have not seen it. But this also does not work. I get errors from MongoDB that it cannot start.

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:

  1. 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).

  2. 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.

  1. 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.
  2. 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 still not reproduce it. Can we make a screensharing session?

Yes, we can. Can you send me an email to … then I can invite you to MsTeams. (Btw: I am also from Berlin)

The dev-5505 works now.

Thank you Sebastian!

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?

I will have a look, how to fix that.

It works exactly like this for me. I tried it with your compose.