Hmm, I took the initial statement about returning 500 at face value when I wrote my response above, but with actual testing I'm not seeing that behavior in any recent version... (tested 9.1, 9.4, 9.5, main) this cause a some confusion since I am working in that code right now and having read this I made sure in paths I added I threw 500 and then discovered that it wasn't reliably thrown all the time when I was testing... I initially assumed I must have broken it until I stashed everything and made this discovery :).
David, what version were you observing 500 status for a time limit exceedance with timeAllowed? Is it an 8.x? I didn't test any of those... Searching an index of the ref guide here which I use for testing sometime (this index is easily created via https://github.com/nsoft/index-solr-ref-guide) in each of those versions I got: { "responseHeader":{ "zkConnected":true, "partialResults":true, "status":0, "QTime":20, "params":{ "q":"hdfs", "indent":"true", "q.op":"OR", "timeAllowed":"1", "useParams":"", "_":"1711914604030"}}, "response":{"numFound":2,"start":0,"maxScore":3.6057181,"numFoundExact":true,"docs":[ Or without timeAllowed: { "responseHeader":{ "zkConnected":true, "status":0, "QTime":66, "params":{ "q":"hdfs", "indent":"true", "q.op":"OR", "useParams":"", "_":"1711914604030"}}, "response":{"numFound":9,"start":0,"maxScore":4.5576544,"numFoundExact":true,"docs":[ As a side quirk, the numFoundExact seems a bit misleading... alongside partialResults:true On Wed, Mar 20, 2024 at 5:59 PM Gus Heck <gus.h...@gmail.com> wrote: > I don't like the current 500. That's sharing the same conceptual space as > NPE, bugs and other hard failures for which IT should be paged at 2:30 am. > > 5xx indicates that there is a problem with the server and that there is > nothing the client can do, and also would typically be flagged by > monitoring tools as a system problem. That's not true, often the query can > be modified, or resubmitted of peak hours etc... The server is not > compromised. > > 4xx indicates that "the client should correct their request" which is true > if things are taking a long time because the request was dumb in the first > place, but since that's entirely relative to the index and the hardware, > it's unknowable from our perspective so it also feels wrong to send a 400, > because it could be a perfectly fine request sent in the middle of a DOS > attack... Not the client's fault. > > Stepping back a moment let's think about the request: it says "run this > query for up to X milliseconds" ... the server did that successfully so > really the response ought to be a success. > > So 206 Partial Content seems to make the most sense > > -Gus > > > On Wed, Mar 20, 2024 at 2:06 PM Chris Hostetter <hossman_luc...@fucit.org> > wrote: > >> >> : I still think 503 is appropriate when timeAllowed is exceeded. The >> : service requested is a reponse within the set time. That service is not >> : available. Here are the RFC definitions of 500 and 503. Exceeding >> : timeAllowed isn’t an “unexpected condition”, it is part of the normal >> : operation of that limit. >> >> Devils avocate argument: it is an "unexpected condition" -- it's >> unepected >> that the request wasn't able to be processed w/in the configured limits. >> If you >> expected that the request could *NOT* be processed, why send it w/those >> limits? >> >> I'm -0 to using 503 because it's worded to very explicitly be a temporal >> situation: failue "due temporary overload or scheduled maintenance" -- >> those aren't *examples* of why a server MAY return 503, those are the >> explict circumstances indicated by a 503 -- and neither one is directly >> applicable for a query limit being exceeded. An otherwise idle server >> might still fail a request with a query limit configured -- regardless of >> wther the server is "overloaded" or down for "scheduled maintenance" -- >> and there is no reason for a client to assume retrying a request with the >> same query limits will succeed again in the future. >> >> >> Bottom line for me: I'm fine w/changing the default response code to >> anything -- as long as we make it configure. But i *strongly* urge us >> not to use a non-standard error code that already has very specific, well >> established, meaning with well known proxy software. >> >> >> : 6.6.1. 500 Internal Server Error >> : >> : The 500 (Internal Server Error) status code indicates that the server >> : encountered an unexpected condition that prevented it from fulfilling >> : the request. >> : https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.1 >> : >> : 6.6.4 503 Service Unavailable >> : >> : The 503 (Service Unavailable) status code indicates that the server >> : is currently unable to handle the request due to a temporary overload >> : or scheduled maintenance, which will likely be alleviated after some >> : delay. The server MAY send a Retry-After header field >> : (Section 7.1.3) to suggest an appropriate amount of time for the >> : client to wait before retrying the request >> : https://datatracker.ietf.org/doc/html/rfc7231#section-6.6.4 >> : >> : Solr could even return 503 with a message of “timeAllowed exceeded”. >> : >> : I spent about a decade working on a search engine with an integrated >> web spider. Accurate HTTP response codes are really useful. >> : >> : wunder >> : Walter Underwood >> : wun...@wunderwood.org >> : http://observer.wunderwood.org/ (my blog) >> : >> : > On Mar 19, 2024, at 3:12 PM, Chris Hostetter < >> hossman_luc...@fucit.org> wrote: >> : > >> : > >> : > Agree on all of Uwe's points below >> : > >> : > I think 500 is the most appropriate for exceeding QueryLimits -- >> : > unless/until we decie we want Solr to start using custom response >> codes in >> : > some cases, but in that case i would suggest we explicitly *avoid* >> using >> : > 504, 524, & 529 precisely because they already have specific meanings >> in >> : > well known HTTP proxies/services that don't match what we're talking >> about >> : > here. >> : > >> : > As far as one of David's specific observations... >> : > >> : > : > ideal IMO because Solr's health could reasonably be judged by >> looking >> : > : > for 500's specifically as a sign of a general error that service >> : > : > operators should pay attention to. >> : > >> : > Any client that is interpreting a '500' error as a *general* >> indication of >> : > a problem with Solr, and not specific to that request, would not be >> : > respecting the spec on what '500' means. *Some* '5xx' are documented >> : > to indicate that there may be a general problem afflicting the >> : > server/service as a whole (notably '503') but most do not. >> : > >> : > But i also think that if we really want to cover our basis -- we can >> : > always make it configurable. Let people configure Solr to return >> : > 500, 400, 418, 666, 999, ... wtf they want ... but 500 is probably >> the >> : > best sane default that doesn't carry around implicit baggage. >> : > >> : > : 524 or 504 both refer to timeouts, but both are meant for proxies >> (so reverse >> : > : proxy can't reach the backend server in time). So both of them do >> not match. >> : > : >> : > : 408 is "request timeout", but that's client's fault (4xx code). In >> that case >> : > : its a more technical code because it also requires to close the >> connection and >> : > : not keep it alive, so we can't trigger that from Servlet API in a >> correct way. >> : > : >> : > : 503 does not fit well as Solr is not overloaded, but would be the >> only >> : > : alternative I see. Maybe add a new Solr-specific one? Anyways, I >> think 500 >> : > : seems the best response unless you find another one not >> proxy-related. >> : > : >> : > : Uwe >> : > >> : > >> : > -Hoss >> : > http://www.lucidworks.com/ >> : > >> : > --------------------------------------------------------------------- >> : > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> : > For additional commands, e-mail: dev-h...@solr.apache.org >> : > >> : >> : >> >> -Hoss >> http://www.lucidworks.com/ >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org >> For additional commands, e-mail: dev-h...@solr.apache.org > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
