502 Bad Gateway problem contacting production server

[katestange]

The URL https://numberscope.colorado.edu/api/get_oeis_factors/A006769/1000 on the production server currently produces 502 Bad Gateway. On a local copy of the current backscope, the URL works fine.

Strangely, the following URLs seem to work fine:

https://numberscope.colorado.edu/api/get_oeis_factors/A006707/1000
https://numberscope.colorado.edu/api/get_oeis_values/A006769/1000

Below is how I discovered this, but probably everything relevant is shown above.

In the current up-to-date frontscope/main, when I run with a local backscope, all is fine. When I run without my own .env.local so it should contact the numberscope server, and I click "Create Bundle" then I get the following in the console:

Access to XMLHttpRequest at 'https://numberscope.colorado.edu/api/get_oeis_factors/A006769/1000' from origin 'http://localhost:5173' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Fronstcope also pops up an error dialog with AxiosError: Network Error. If you try the URL above directly, you get 502 Bad Gateway.

To reproduce, call sequence A006769, then choose "Factor Histogram" and create bundle. It appears that for this sequence, only visualizers which wish to call for factors are affected. OTOH, some other sequences seem to work just fine. So it's a very specific bug and maybe it has to do with the state of the database on the backend? But why would that return Bad Gateway? Really kind of weird.

[katestange]

If it is a database issue on the backscope server, then it should return something more informative than Bad Gateway.

[gwhitney]

How critical do you think debugging this is? If I review, merge, and install #127, it will blow away any database state that is causing this particular URL to choke, making it likely very hard to reproduce and track down this bug. On the other hand, for getting the back end into shape for the Delft Team, it's pretty urgent for me to move #127 along. Thoughts?

[katestange]

Did anyone else test it? To make sure it isn't just my end? I loaded up things a few hours later and I think the behaviour changed a little (not sure).

[katestange]

How critical do you think debugging this is? If I review, merge, and install #127, it will blow away any database state that is causing this particular URL to choke, making it likely very hard to reproduce and track down this bug. On the other hand, for getting the back end into shape for the Delft Team, it's pretty urgent for me to move #127 along. Thoughts?

I think you should definitely move #127 along including installing on the server and we'll just have to see. If we can't find the bug afterward, it isn't (apparently) urgent.

[gwhitney]

Did anyone else test it? To make sure it isn't just my end? I loaded up things a few hours later and I think the behaviour changed a little (not sure).

Indeed, https://numberscope.colorado.edu/api/get_oeis_factors/A006769/1000 currently produces an "Internal Server Error".

[gwhitney]

I will save the latest log as backscopeIssue128.log in ~scope when I install the next version of backscope, in case it will help someone to be able to debug the issue in the future. When this issue is resolved or otherwise closed, please remove that file.