So i built a thing: SQL transport http passthrough Community extensions and integrations • NServiceBus • Particular Docs
I have a design decision i am unsure about. Currently if an invalid http request comes in, the client is returned a BadRequest 400 is returned to the client. Community extensions and integrations • NServiceBus • Particular Docs
An alternate way of handling this would be writing the request to a sql error queue and returning a success to the client.
So… thoughts? if a bad request is detected, should that bubble back to the client or go to a sql queue?
Hey Simon,
Given that the initiating request comes in through HTTP in case of a bad
request I’d expect a bad request response not a 200. The client might make
a decision based on the server response and if the response is OK but the
message in not dispatched anywhere because it’s effectively a bad request
it’s basically opening for a corruption in the system integrity.
.m
message in not dispatched anywhere because it’s effectively a bad request
it’s basically opening for a corruption in the system integrity
I didnt say “not dispatched”. I said “or go to a sql queue”. Ie in a similar way to how the error queue works.
Yup, however being a bad request it’s probably non-dispatchable, regardless
of where it is. Correct? In Which case what’s the point of returning OK
.m
however being a bad request it’s probably non-dispatchable, regardless of where it is. Correct? In Which case what’s the point of returning OK
not exactly. it depends on what u consider a bad request, and the way in which you want to handle those cases. There are two scenarios that could result in a bad request, a bug or a malicious request. there is no programmatic way to distinguish between the two. however the more common is most likely to be a bug, eg some mist match between the client and backend contract assumptions. in this case how should that be handled, i know from my perspective i would rather that message is forwarded to the error queue with all applicable state to help debug the issue. it would be much easier to debug from that perspective than to have it returned to the client.
i think, in this case, the client should be considered a send only endpoint. and in that scenario, if the sender dispatches a bad message, the receiver does not reply with “bad message”, it forwards the offending message to the error queue.
But we’re specifically talking about HTTP that has a semantic for errors,
e.g. bad request. Being HTTP synchronous I ring it very hard to compare it
with a messaging endpoint where the only possible semantic is fire and
forget.
As a client in such a scenario the only thing I’d find acceptable is a 202,
not a 200, and then a mechanism to let me know that something went badly.
It might simplify things for the Ops team as they a persistent message in
an error queue, however I’d try to answer at first a question such as: can
such a message be retried ever?
If the buggy code is client side, the message is malformed and it can’t be
retried. Having it as a persistent message in a queue is nothing more
than a log on steroids. It’s handy for sure, if that’s the case maybe a
dedicated poison queue is better than a generic error queue. But I’d not
return 200 to the client in any case.
.m