No, 425 is something specific A 503 Service Unavailable seems the only suitable standard code.
B. > On 24 Mar 2020, at 08:48, Glynn Bird <glynn.b...@gmail.com> wrote: > > If a user didn't specify the index they wanted to use, leaving the choice > of index up to CouchDB, I would expect Couch would ignore the partially > built index and fall back on _all_docs. so +1 on this. > > But we need also consider the API response if a user *specifies* an index > during a query (with use_index) when that index is not built yet, I think I > would prefer an instant 4** response indicating that the requested > resource isn't ready yet, rather than performing a very slow, > _all_docs-powered search. Is "425 Too Early" a suitable response? > > > > >> On Mon, 23 Mar 2020 at 23:30, Joan Touzet <woh...@apache.org> wrote: >> >> >> >>> On 2020-03-23 4:46 p.m., Mike Rhodes wrote: >>> Garren, >>> >>> Very much +1 on this suggestion, as it is, at least for me, what I'd >> expect to happen if I were leaving the system to select an index -- as you >> imply, the build process almost certainly takes longer than using the >> _all_docs index. In addition, for the common case where there is a less >> optimal but still useful index available, one might expect that index to be >> used in preference to the "better" but unbuilt one. >> >> I agree. >> >>> But I do think this is important: >>> >>>> We can amend the warning message >>>> to let them know that they have an index that is building that could >>>> service the index when it's ready. >>> >>> Otherwise it's a bit too easy to get confused when trying to understand >> the reason why an index you were _sure_ should've been used in fact was not. >> >> Question: Imagine a node that's been offline for a bit and is just >> coming back on. (I'm not 100% sure how this works in FDB land.) If >> there's a (stale) index on disk, and the index is being updated, and the >> index on disk is kind of stale...what happens? >> >> -Joan >>
