Vinz2168 opened a new pull request, #11885: URL: https://github.com/apache/nifi/pull/11885
<!-- Licensed to the Apache Software Foundation (ASF) under one or more --> <!-- contributor license agreements. See the NOTICE file distributed with --> <!-- this work for additional information regarding copyright ownership. --> <!-- The ASF licenses this file to You under the Apache License, Version 2.0 --> <!-- (the "License"); you may not use this file except in compliance with --> <!-- the License. You may obtain a copy of the License at --> <!-- http://www.apache.org/licenses/LICENSE-2.0 --> <!-- Unless required by applicable law or agreed to in writing, software --> <!-- distributed under the License is distributed on an "AS IS" BASIS, --> <!-- WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. --> <!-- See the License for the specific language governing permissions and --> <!-- limitations under the License. --> # Summary [NIFI-16542](https://issues.apache.org/jira/browse/NIFI-16542) Removing a single cluster state key (`POST .../state/clear-requests` with a `ComponentStateDTO`) is replicated to every node, but the cluster state itself is shared. The first node validates the request with `hasExactlyOneKeyRemoved`, writes the new state and returns 200. A node that processes the request afterwards sees the already-updated state, fails the validation and returns 409, so the cluster coordinator requests that node to reconnect. This is what makes `ClusterStateKeyDropIT.testCanDropSpecificStateKey` fail on `main` since NIFI-16494 (`Node localhost:5672 is currently connecting` at line 133): the extra `runProcessorOnce()` added there runs while the node is reconnecting. This change makes the selective cluster state key removal idempotent across replicated requests: when the cluster state provider is enabled and the current cluster state already equals the requested state, the request is treated as already applied by another node instead of failing. Standalone behavior and local state handling are unchanged, and removing more than one key or changing values is still rejected. Note that in a cluster a request that removes no key is now accepted as a no-op instead of returning 409, since a node cannot distinguish it from a replicated request already applied by another node. Verification: - New `StandardComponentStateDAOTest`, including a test that processes the same request twice against shared cluster state (fails without the change with the same `IllegalStateException` seen in CI). - `ClusterStateKeyDropIT` run locally against a 2-node cluster. The race does not occur naturally on my machine, so as a temporary local experiment (not part of this PR) node 2 was delayed before reading the cluster state to force the CI ordering: without this change 3/3 runs failed at `testCanDropSpecificStateKey:133` with the node disconnected; with this change 3/3 runs passed with no node disconnection. Without the delay, 10/10 runs passed with this change. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [x] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [x] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-00000` - [x] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-00000` - [x] Pull request contains [commits signed](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits) with a registered key indicating `Verified` status ### Pull Request Formatting - [x] Pull Request based on current revision of the `main` branch - [x] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [x] Build completed using `./mvnw clean install -P contrib-check` (nifi-web-api module) - [ ] JDK 21 - [ ] JDK 25 Built and tested locally on JDK 26; relying on CI for JDK 21 and 25. ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [ ] Documentation formatting appears as expected in rendered files 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
