HanShuhang opened a new pull request, #7642:
URL: https://github.com/apache/kyuubi/pull/7642
<!--
Thanks for sending a pull request!
Here are some tips for you:
1. If this is your first time, please read our contributor guidelines:
https://kyuubi.readthedocs.io/en/master/contributing/code/index.html
2. If the PR is related to an issue in
https://github.com/apache/kyuubi/issues, add '[KYUUBI #XXXX]' in your PR title,
e.g., '[KYUUBI #XXXX] Your PR title ...'.
3. If the PR is unfinished, add '[WIP]' in your PR title, e.g.,
'[WIP][KYUUBI #XXXX] Your PR title ...'.
-->
### Why are the changes needed?
<!--
Please clarify why the changes are needed. For instance,
1. If you propose a new API, clarify the use case for a new API.
2. If you fix a bug, you can clarify why it is a bug, and what versions
are affected.
-->
`KyuubiOperation#setState` updated operation state metrics before delegating
to `AbstractOperation#setState`, where the state transition is validated and
the actual operation state is changed. It also did not protect the whole
transition-and-metrics-update sequence with the operation lock.
This can cause inaccurate operation state metrics in two cases:
1. A stale or invalid state transition may update metrics before being
rejected.
For example, an operation may have already moved from `RUNNING` to
`FINISHED`, while a delayed cancel/close path still tries to update it to
another terminal state such as `CANCELED`. In the old implementation, the
target state metric was updated before `OperationState#validateTransition`
rejected the transition, so the operation remained in the original state but
the metrics had already been changed.
2. Concurrent state transitions for the same operation may update metrics
based on the same stale old state.
For example, one thread may observe the remote query as finished and
call `KyuubiOperation#setState(FINISHED)`, while another thread concurrently
handles cancel/close/timeout/error and calls
`KyuubiOperation#setState(CANCELED)` or another terminal state. Since the old
implementation read `state` and updated metrics outside a common operation
lock, both paths could observe the old state as `RUNNING` and both update the
`RUNNING` metric, making `kyuubi.operation.state.ExecuteStatement.running`
inaccurate.
This patch makes `KyuubiOperation#setState` execute under the operation
lock, captures the old state once, delegates to `AbstractOperation#setState`
first, and updates operation state metrics only after the state transition
succeeds.
### How was this patch tested?
<!--
If tests were added, say they were added here. Please make sure to add some
test cases that check the changes thoroughly including negative and positive
cases if possible.
If it was tested in a way different from regular unit tests, please clarify
how you tested step by step, ideally copy and paste-able, so that other
reviewers can test and check, and descendants can verify in the future.
If tests were not added, please describe why they were not added and/or why
it was difficult to add.
-->
Added a unit test in `KyuubiOperationSuite` to verify that a stale terminal
transition does not update operation state metrics.
### Was this patch authored or co-authored using generative AI tooling?
<!--
If generative AI tooling has assisted in authoring or reviewing this patch,
please include
an 'Assisted-by: ' trailer that identifies the agent and model.
For example: 'Assisted-by: Claude:claude-opus-4-7' or 'Assisted-by: Claude
Opus 4.7'.
If no, write 'No'.
Please refer to the [ASF Generative Tooling
Guidance](https://www.apache.org/legal/generative-tooling.html) for details.
-->
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
