feat(search): report why a search result is partial - #8
Merged
Merged
Conversation
With codelibs/fess#3440, Fess flags a result partial when the query timeout elapsed as well as when a shard failed, and SearchRenderData says which of the two happened. /api/v1/documents only passed partial through, so a client still could not tell a timeout from a failed shard. The response now carries timed_out and shard_failed right after partial, and openapi-user.yaml declares both. partial keeps its meaning. openapi-user.yaml still said 15.7.0 and linked the 15.7 documentation; 15.8.0 shipped it that way. It now says 15.9.0, the release this response ships in, and links the 15.9 documentation.
marevol
force-pushed
the
feat/report-why-results-are-partial
branch
from
September 13, 2026 05:50
bf73554 to
c2a9da4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Depends on codelibs/fess#3440.
codelibs/fess#3440 fixes the partial-results flag in Fess. It used to be set only when a shard failed, while the search UI and the log called that a timeout, and a real query timeout was not flagged at all. After it,
partialis set for both,SearchRenderDatagainsisTimedOut()andisShardFailed()to say which, and/api/v2/searchin Fess core returns them astimed_outandshard_failed.This does the same for
/api/v1/documents: the search response hastimed_outandshard_failedright afterpartial, andopenapi-user.yamldeclares both.partialkeeps its meaning, so existing clients are unaffected.openapi-user.yamlalso still saidinfo.version: 15.7.0and linked the 15.7 documentation; the 15.8.0 release shipped it that way, because the version bumps touch onlypom.xml. It now says 15.9.0, the release this response ships in, and links the 15.9 documentation.Testing
SearchHandlerTestrunsSearchHandler#handleagainst a stubbedSearchHelperand checks the JSON for a shard failure, a timeout, and a complete result. All three failed before the change, because neither key was in the body.maindoes not compile against current Fess until fix(favorite): follow the three-valued addUrl contract #7 lands (FavoriteLogServicenow returnsFavoriteResult), so the change was verified on top of fix(favorite): follow the three-valued addUrl contract #7 against a Fess jar built from fix(search): tell a query timeout apart from a failed shard fess#3440: 205 tests, 0 failures.FavoriteHandlerTestfrom fix(favorite): follow the three-valued addUrl contract #7 was left out of that local run because it targets packages from a Fess change that is not merged yet.Merge order
CI compiles against the published Fess snapshot, so it cannot pass until codelibs/fess#3440 is merged and a snapshot is deployed, and #7 is merged.