Check every API request for correct content type

[kolaente]

Description
Opening the cookbook app in a browser shows a loading spinner at "categories", does not seem to load anything (from the network tab and completely freezes the browser to the point where Firefox would offer to kill the tab. This looks like it is running into some kind of endless loop.

Reproduction
Steps to reproduce the behavior:

1. Open the cookbook app in the browser

Expected behavior
App working normally like it used to.

Actual behavior
Not working, locks up browser

Screenshots

This is what that looks like when it locks up:

Browser

Tested in Firefox 104.0.2 and Chromium 105.0.5195.125, both on Linux (NixOS).

Versions
Nextcloud server version: 24.0.1
Cookbook version: 0.9.15
Database system: MariaDB

[christianlupus]

Can you please open the developer tools before navigating to the cookbook app? There should be a few requests running. Potentially, the JS is not loading successfully. Could you please check this?

[kolaente]

It looks like all assets are loaded successfully.

[MarcelRobitaille]

Have you checked specifically for cookbook-main.js? Nextcloud itself loads many assets outside of this app, so it may not be obvious whether this app's assets are loaded. In the network tab, you can filter for cookbook, which for me shows that cookbook-main.js is being loaded (I have highlighted it in the screenshot).

[kolaente]

@MarcelRobitaille Yes that file gets loaded.

[MarcelRobitaille]

@kolaente Are there any errors in the console?

[kolaente]

Only CSP warnings, not sure if they are related:

[MarcelRobitaille]

@kolaente Thanks. No, I also always get those. I don't think it's that.

Not working, locks up browser

What do you mean by this? Does the entire browser become unresponsive? Are other tabs and the browser's buttons also misbehaving / responding slowly?

[kolaente]

Does the entire browser become unresponsive? Are other tabs and the browser's buttons also misbehaving / responding slowly?

Other tabs get slowed down a bit but are still usable. The tab with the cookbook open is completely unresponsive. Firefox uses two cpu cores at 100% during the unresponsiveness.
Firefox offers me to stop the tab after a few minutes:

[MarcelRobitaille]

Do you think you could go the the "Performance" tab of the developer tools and take a profiler recording? That could help us figure out what the page is stuck doing.

[kolaente]

Here's a performance record: https://share.firefox.dev/3s9oryG

At ~3.5 sec mark the page was loaded and started to freeze.

[MarcelRobitaille]

@kolaente Thanks very much for that. I hoped there would be a little more information about the calls, but alas. I looks like getCategories is being called repeatedly from 4.75s to 6.25s, then all the time is spent in totalRecipeCount.

@christianlupus Do you have a proposal of how to debug this? My instinct would be to have @kolaente try a new branch with some console.log thrown in, but maybe this is an opportunity to add some more permanent logging?

[kolaente]

@MarcelRobitaille These two functions look like they have potential for an infinite loop. Would you accept a PR with a refactor to forEach or similar?

[MarcelRobitaille]

@kolaente I don't see how either of these could create an infinite loop. The loop variables are not being modified in the body of the loop. Furthermore, getCategories is being called multiple times, it's not being called once and getting stuck. I proposed the logging so we could wee from where getCategories is being called.

[christianlupus]

If you open the debugger console before you navigate to the cookbook app and switch to the network tab, you should see all requests that are carried out by the frontend. Is the number when opening the cookbook app flowing through like an avalanche? Are the requests finished at some time (return code in the first column appears)?

Did the app work once?

Apart from that, I think the problem is most probably in the front end and I suspect some nasty thing there. I have it running with a very similar configuration and I do not see any problems.

Related to your question about debugging: I was considering adding a boolean flag that will allow the user to temporarily enable debugging in the browser console. Something like a checkbox in the settings 😉 that is not stored and thus reset to false in case of reloading the page.

I fear this is not a good solution in itself here as it is not possible to activate that before the user can visit the main page. It might however be a good idea to implement the logging and create a branch where the logging is enabled by default. Then, @kolaente can test using this branch.

What do you think of this idea, @MarcelRobitaille?

[MarcelRobitaille]

@christianlupus Yes, I was thinking something similar. If we want to see output in the console, and if the settings UI hasn't loaded yet, what if we have the user run a command in the console to enable logging before navigating to the cookbook app? We could use localstorage. Maybe we could make it reset automatically after a certain time?

[christianlupus]

That sounds very reasonable. I would let that to you, if you do not mind. You are way more experienced in js than me. If you want, you can add another issue to keep track of progress.

I will try to prepare the nc25 release soon. So, please be prepared to rebase if you start to implement things.

[kolaente]

If you open the debugger console before you navigate to the cookbook app and switch to the network tab, you should see all requests that are carried out by the frontend. Is the number when opening the cookbook app flowing through like an avalanche? Are the requests finished at some time (return code in the first column appears)?

There's a bunch of requests happening intially for ~1-3 seconds. After that the list stays consistent at 71 requests.

Did the app work once?

Yes. Right now that's my biggest problem because I have quite a few recipes in there and can't open them now.

---

While looking at the network tab I saw something else: The requests to /apps/cookbook/webapp/categories, /apps/cookbook/webapp/config and /apps/cookbook/webapp/recipes all return a 302 and redirect to the dashboard at /apps/dashboard/. I assume those are the calls to get everything as json?

[christianlupus]

There's a bunch of requests happening intially for ~1-3 seconds. After that the list stays consistent at 71 requests.

At least we are not facing an infinite loop, I was fearing.

Yes. Right now that's my biggest problem because I have quite a few recipes in there and can't open them now.

The good news is: Your recipes are safe, even from yourself 😉. No, to be serious: The recipes are stored as files and can be accessed anytime you like.

While looking at the network tab I saw something else: The requests to /apps/cookbook/webapp/categories, /apps/cookbook/webapp/config and /apps/cookbook/webapp/recipes all return a 302 and redirect to the dashboard at /apps/dashboard/. I assume those are the calls to get everything as json?

Yes, that sounds strange. These should return JSON data. When HTML data (with the redirect) is used and parsed as JSON, that might cause some hiccups. So, there is for sure some problem with the backend so far.

Do you see any errors in the nextcloud.log file appearing?

You could try to disable and reenable the cookbook app once in the backend to make sure, it is registered accordingly.

If you are familiar with curl, you can trigger the command to get the categories by

curl https://example.com/apps/cookbook/api/v1/categories -v -u user:user_pwd

Let's see what happens then. Just post the output here carefully (redact any data in a header mentioning cookies or authorization!)

[kolaente]

I tried disabling and re-enabling the app with no luck. Then I noticed my instance was still on 24.0.1 so I upgraded it to 24.0.6... and now everything works as expected. Looks like this wasn't an issue in the cookbook app after all. It's probably still a good idea to add a check before looping over the json data to avoid these loops.

[MarcelRobitaille]

@christianlupus Would #1283 be helpful here or have we moved passed that?

[christianlupus]

The problem is solved for the thread starter. So, this is done.

I would suggest adding a generic log to the API Axios request generator. Something that logs basic information about all requests carried out. What are you thinking about that, @MarcelRobitaille?

[christianlupus]

PS: Also, all requests could be assigned a check if they contain application/json or text/json and issue a warning if not (possibly configurable).

[MarcelRobitaille]

@christianlupus Something like that? https://github.com/MarcelRobitaille/cookbook/blob/axios-logging/src/js/api-interface.js

[christianlupus]

Yeah, sort of. I might have realized it differently but the main point it is.

[MarcelRobitaille]

I am open to suggestions. What would you have changed? After that, shall I create a pull request?

[christianlupus]

All right. I was not aware of the option to incept. Open a PR and we never this directly.