Fail SearchV2 requested with unreachable queries #1356

New issue

Open

opened 2025-12-28 17:22:41 +00:00 by sami · 2 comments

sami commented

2025-12-28 17:22:41 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Feb 19, 2025).

no object can ever match following queries:

N < X && N > X-like
N < -MaxUint256, N <= -MaxUint256-POS, N > MaxUint256, N >= MaxUint256+POS
???

1 is 4ever false while 2 is a current protocol limit (false until extensions)

currently, SearchV2 server responds w/ empty result and OK to any mentioned query. From one side, this is correct: no object matches these filters. From the other one, when OK recved, client cannot distinguish "not found for now" from "not found and will never be" states. This can hide some app-side bugs and worsen the understanding of sys behavior

Describe the solution you'd like

respond to unreachable queries with particular status:

Bad Request to limit overflows
specific non-zero one to unreachable queries (can also be 400)

Describe alternatives you've considered

keep returning empty OK result

Additional context

#3058
#1148

Originally created by @cthulhu-rider on GitHub (Feb 19, 2025). ## Is your feature request related to a problem? Please describe. no object can ever match following queries: 1. `N < X && N > X`-like 2. `N < -MaxUint256`, `N <= -MaxUint256-POS`, `N > MaxUint256`, `N >= MaxUint256+POS` 3. ??? 1 is 4ever false while 2 is a current protocol limit (false until extensions) currently, `SearchV2` server responds w/ empty result and `OK` to any mentioned query. From one side, this is correct: no object matches these filters. From the other one, when OK recved, client cannot distinguish "not found for now" from "not found and will never be" states. This can hide some app-side bugs and worsen the understanding of sys behavior ## Describe the solution you'd like respond to unreachable queries with particular status: * `Bad Request` to limit overflows * specific non-zero one to unreachable queries (can also be `400`) ## Describe alternatives you've considered keep returning empty `OK` result ## Additional context * #3058 * #1148

sami added the

enhancement

neofs-storage

discussion

labels

2025-12-28 17:22:41 +00:00

sami commented

2025-12-28 17:22:41 +00:00

Author

Owner

@roman-khimov commented on GitHub (Feb 19, 2025):

I'm somewhat concerned about deliberately slow queries. We're mostly making them to be efficient since we need performance and fast replies, but an attacker can make v2 work about the same time as v1 did returning zero or some small number of results. And this would be cluster-wide. I don't see a lot of ways to solve it other than some timeouts, but those wont't be trivial either (need to be checked while iterating over the DB).

@roman-khimov commented on GitHub (Feb 19, 2025): I'm somewhat concerned about deliberately slow queries. We're mostly making them to be efficient since we need performance and fast replies, but an attacker can make v2 work about the same time as v1 did returning zero or some small number of results. And this would be cluster-wide. I don't see a lot of ways to solve it other than some timeouts, but those wont't be trivial either (need to be checked while iterating over the DB).

sami commented

2025-12-28 17:22:41 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Feb 19, 2025):

sounds like QoS control with limits and a fee for the load. In theory, it sounds interesting, in practice, we aint even close

@cthulhu-rider commented on GitHub (Feb 19, 2025): sounds like QoS control with limits and a fee for the load. In theory, it sounds interesting, in practice, we aint even close