Allow overriding MAX_PARALLEL_REQUESTS_PER_DOC from env #920
Conversation
| @@ -98,7 +98,7 @@ import { Document } from "app/gen-server/entity/Document"; | |||
| // Cap on the number of requests that can be outstanding on a single document via the | |||
| // rest doc api. When this limit is exceeded, incoming requests receive an immediate | |||
| // reply with status 429. | |||
| const MAX_PARALLEL_REQUESTS_PER_DOC = 10; | |||
| const MAX_PARALLEL_REQUESTS_PER_DOC = process.env.MAX_PARALLEL_REQUESTS_PER_DOC || 10; | |||
There was a problem hiding this comment.
Shouldn't it be called with parseInt ?
There was a problem hiding this comment.
@nafg are you interested in completing this work? It would be a useful improvement, you are not the first to want this number to be customizable.
There was a problem hiding this comment.
Support said there was no point since it's just a queue over a single request at a time bring processed, IIUC.
Either way, it was an urgent need and had already been utterly disastrous for my client. I had written an IVR for them using Grist as the persistence and admin UI and that was a big mistake. Instead I had to do a marathon migration to a proper RDBMS with a custom UI.
Migrating could have been easier too, if the sqlite data was somewhat normalized (e.g. values in Boolean columns were in all different formats) so I could use pgloader. The only sane way ended up being to write a custom script against the rest API.
So in the end migrating from the SaaS to self -hosted was a waste of time. It's unclear whether this PR would have changed that but by now it's far too late and it's no longer useful to me.
Of course no one's to blame, but I wish these limitations would have been much advertised much more prominently and clearly up front.
No description provided.