[
https://issues.apache.org/jira/browse/CASSANDRA-21739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18138777#comment-18138777
]
Suvidh Jain commented on CASSANDRA-21739:
-----------------------------------------
I would like to take this on. Could this be assigned to me?
I would perform floor()'s argument checks on the coordinator, inside the
selector's {{validateForGroupBy()}}, which already verifies {{isMonotonic()}}
(both come from CASSANDRA-11871). If the duration and starting time are
constants or bind markers, the client then receives the same InvalidRequest and
message as it would outside GROUP BY. That handles a duration under 1
millisecond, a negative duration, under 1 day for date values, and 1 day or
more for time values.
It cannot handle a starting time that is later than the value, since that
depends on the row. In that case the replica's error would need to reach the
client as an invalid request, and {{RequestFailureReason}} has no code for it,
so this appears to be a larger change. Would a partial fix be acceptable, with
that case handled as a follow-up?
There is one behaviour change: an invalid constant would fail even when no rows
match, whereas today it returns nothing. Non-monotonic functions in GROUP BY
already fail in that way.
I have it for cassandra-5.0, cassandra-6.0 and trunk, with a SelectGroupByTest
case over the native protocol and an in-JVM GroupByTest case on two nodes. Both
of them fail without the fix. 4.1 has the same bug: 10us and -1h produce the
same read failure there. The patch does not apply cleanly to 4.1, so it would
need to be ported. Should it also go to 4.1? I don't have access to pre-commit
CI, so could a committer run it once I've posted the branches?
> floor() in GROUP BY reports invalid arguments as a ReadFailure instead of an
> InvalidRequest
> -------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21739
> Project: Apache Cassandra
> Issue Type: Bug
> Reporter: Nadav Har'El
> Priority: Normal
>
> When floor() is used in a GROUP BY clause with an invalid duration or
> starting time, the request fails with a ReadFailure ("Operation failed -
> received 0 responses and 1 failures: UNKNOWN from ...") instead of an
> InvalidRequest error. The InvalidRequestException is thrown on the replica
> while reading, and appears only in the server's log:
> {code:sql}
> CREATE TABLE ks.t (pk int, time timestamp, v int, PRIMARY KEY (pk, time));
> INSERT INTO ks.t (pk, time, v) VALUES (1, '2016-09-27 16:10:00 UTC', 1);
> SELECT pk, floor(time, 10us), min(v) FROM ks.t GROUP BY pk, floor(time, 10us);
> {code}
> {noformat}
> ReadFailure: Error from server: code=1300 [Replica(s) failed to execute read]
> message="Operation failed - received 0 responses and 1 failures: UNKNOWN from
> /127.0.0.1:7000"
> {noformat}
> The server log shows:
> {noformat}
> java.lang.RuntimeException:
> org.apache.cassandra.exceptions.InvalidRequestException: The floor cannot be
> computed for the 10us duration as precision is below 1 millisecond
> {noformat}
> The same happens for the other argument checks of floor() in GROUP BY: a
> negative duration, a starting time later than the value, a duration below 1
> day for date values, and a duration of a day or more for time values. In
> contrast, the same floor() call outside GROUP BY (e.g. SELECT floor(time,
> 10us) FROM ks.t WHERE pk = 1) correctly fails with InvalidRequest.
> Reproduced on Cassandra 5.0.9 and 6.0-alpha2. SelectGroupByTest
> (testGroupByTimeRanges*WithoutPaging) checks these errors with
> assertInvalidMessage(), but doesn't notice the problem, because CQLTester's
> execute() runs the query internally, where the InvalidRequestException
> surfaces unwrapped.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
