We seem to get blocked in web nodes when much data is being POSTed.
The endpoint should move to call the data-adding logic in a queued job, so that API endpoints stay as light-weight as possible (which is a good design principle). We need to add a bew queue type for this, maybe "ingestion". If there are no workers connected to the queue, print a warning and process the logic directly instead of a job.
Monitoring of things going wrong is then also moved to monitoring job queues, which we'll have to do anyways (but not in this PR).
However, direct user feedback (when the input data cannot be accepted for some reason) might be diminished (is there some straightforward manner we can use to test if data is in order, so we can give the user direct feedback before queueing the job?).
But I can't recall of that actually happening a lot in the current version. More likely is that data was sent, but things turn sideways later when it is being used. Also, now we run the risk of returning 500 errors for timing out, which is also not informative.
We seem to get blocked in web nodes when much data is being POSTed.
The endpoint should move to call the data-adding logic in a queued job, so that API endpoints stay as light-weight as possible (which is a good design principle). We need to add a bew queue type for this, maybe "ingestion". If there are no workers connected to the queue, print a warning and process the logic directly instead of a job.
Monitoring of things going wrong is then also moved to monitoring job queues, which we'll have to do anyways (but not in this PR).
However, direct user feedback (when the input data cannot be accepted for some reason) might be diminished (is there some straightforward manner we can use to test if data is in order, so we can give the user direct feedback before queueing the job?).
But I can't recall of that actually happening a lot in the current version. More likely is that data was sent, but things turn sideways later when it is being used. Also, now we run the risk of returning 500 errors for timing out, which is also not informative.