413 errors, maybe triggered by "too large" requests for genes

[adf-ncgr]

We all know there is no request for genes too large, but I was recently seeing some errors like this, possibly triggered by requests with neighborhoods of 100s of genes (which even "normal" users can make without intending to, when moving about in the macrosynteny view from a region of low gene density to a region of higher density) :
Failed to load resource: the server responded with a status of 413 ()

it looks like this is probably some sort of nginx config setting that can be tweaked. Not going to try such tweaking now but wanted to note the possible issue while it was still somewhat fresh in my mind (found the issue half-written in a window I popped open earlier in the week...)

[adf-ncgr]

Here's an example of a mere 200 gene neighborhood that seems to be triggering the 413 at least occasionally in my set-up:
https://gcv.legumeinfo.org/gcv2/gene;lis=phavu.G19833.gnm2.ann1.Phvul.002G114200?algorithm=repeat&match=10&mismatch=-1&gap=-1&score=30&threshold=25&bmatched=20&bintermediate=10&bmask=10&linkage=average&cthreshold=20&neighbors=200&matched=4&intermediate=5&sources=lis&bregexp=&border=chromosome&regexp=&order=distance

to be fair, I think the 200 neighborhood is OK for the query track genes, and it's the ~200xN of the result tracks that is the trigger.

[nathanweeks]

I wonder if the HTTP 413 was emitted from the gcv service's nginx, traefik, or perhaps a front-end nginx reverse proxy (if there is one)? If somewhere in nginx-land, client_max_body_size looks to be the relevant setting.

[adf-ncgr]

I don't think there's any nginx going on outside containerland in our set-up. I haven't tried to track down exactly where it's being thrown, I just saw it in the browser console. It's kind of surprising to me that we'd be exceeding the default of 1m in my case, but I haven't done the math on how it all adds up. In any case, it wasn't immediately obvious to me where to inject nginx config directives in the current deployment scheme, but if you know offhand please let me know; otherwise it can wait until I have more time to dig or @alancleary is back.

[alancleary]

Thanks for reporting this @adf-ncgr. Using the Network Monitor in Mozilla I can only recover a truncated copy of the genes request body for the example you linked. Even then, the truncated body exceeds 1,000,000 characters!

GCV is already setup to send multiple gene requests and aggregate the results because it supports federation; I think a good, robust solution would be to take gene requests that exceed a certain size and chunk them into multiple requests. Then, in theory, we could support arbitrarily large requests! Any thoughts on this?

[adf-ncgr]

chunking sounds like a reasonable approach to me, if you think it will be less complicated than (or have some other benefit over) trying to tweak the nginx config to handle larger requests. "arbitrarily large" sounds pretty fun, though. I guess we might have to think about how error handling would work in this scenario (ie if some chunks succeed and others fail). It might make sense to think about chunking by result track (assuming that one result would not exceed the current request limit). maybe there are reasons that a request per track would incur too much overhead, but in some ways it seems like the most natural way to chunk things such that failures could at least be isolated to discrete units in the UI.

[alancleary]

That's a good suggestion, and it would be easy to implement since the current mechanism for fetching genes translates tracks into gene requests by binning the genes by source, i.e. the requests would be binned by track instead of source. I'll probably still check that requests aren't too large and chunk them if they are just to maintain support for arbitrarily large tracks!

[adf-ncgr]

you had me at arbitrarily large sets of arbitrarily large tracks...

[alancleary]

The set of tracks itself isn't arbitrarily large since it's derived from GCV's URL but the tracks themselves can be arbitrarily large ;)

[adf-ncgr]

Oh, but I was thinking of result sets, which can easily become arbitrarily large with the right choice of relaxed matching params (cue evil laugh)