Delegate TransportUpdateAction to TransportBulkAction #17679
Conversation
github-actions
bot
added
>breaking
|
❌ Gradle check result for a432e47: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for a432e47: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
| private final NodeClient client; | ||
| private final ClusterService clusterService; | ||
| @Deprecated | ||
| public class TransportUpdateAction extends HandledTransportAction<UpdateRequest, UpdateResponse> { |
There was a problem hiding this comment.
Could we remove this class all together? Seems to not be widely used: https://github.com/search?q=org%3Aopensearch-project%20TransportUpdateAction%20NOT%20is%3Aarchived&type=code
There was a problem hiding this comment.
So, the @Deprecated annotation was copied from TransportIndexAction and TransportDeleteAction.
In practice, I don't think I actually want to remove it. I should probably remove the annotation. (We should probably remove the annotations from TransportIndexAction and TransportDeleteAction since I don't think they're ever going to be removed either.)
There was a problem hiding this comment.
There -- I removed this annotation and the ones on TransportIndexAction, TransportDeleteAction, and TransportSingleItemBulkAction.
msfroh
requested review from
Bukhtawar,
CEHENKLE,
Rishikesh1159,
anasalkouz,
ashking94,
bugmakerrrrrr,
cwperks,
dblock,
dbwiddis,
gbbafna,
jainankitk,
kotwanikunal,
linuxpi,
mch2,
nknize,
owaiskazi19,
reta,
sachinpkale and
saratvemulapalli
as code owners
msfroh
requested review from
VachaShah,
shwetathareja and
sohami
as code owners
|
❌ Gradle check result for 22a2df3: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for c943a65: Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for c943a65: Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for c943a65: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for ffda134: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
❌ Gradle check result for b179c0f: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
server/src/main/java/org/opensearch/action/update/TransportUpdateAction.java
Show resolved
Hide resolved
|
❌ Gradle check result for 07f54e6: Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
There are 26 BWC and IT test failures logged in https://build.ci.opensearch.org/job/gradle-check/55554/#showFailuresLink. Requests originating from 2.x clusters expect to find a shard-level update action. I'll see if I can bring back the shard-level action for BWC, but mark it as deprecated to be removed in 4.0. |
|
❌ Gradle check result for 1d19b4f: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
This is consistent with TransportIndexAction and TransportDeleteAction, and ensures that updates behave consistently, whether sent via the `_update` API or via the `_bulk` API. Signed-off-by: Michael Froh <[email protected]>
Signed-off-by: Michael Froh <[email protected]>
Since this change modifies how updates behave with ingest pipelines, the tests need to be updated to reflect the new behavior (where single item updates behave the same as bulk updates). Signed-off-by: Michael Froh <[email protected]>
… and children In practice, these adapter classes are unlikely to be removed, unless we drop support (at the API level) for the single-item operations. Since the single item operations are likely to stick around, we have no plan to remove these adapter classes. Signed-off-by: Michael Froh <[email protected]>
Signed-off-by: Michael Froh <[email protected]>
Now that it's not the parent of TransportUpdateAction, it's unused. Signed-off-by: Michael Froh <[email protected]>
In a mixed-cluster environment, nodes running on 2.x will still try to dispatch the node-level update action to 3.x shards. We can't remove the node-level action (in favor of TransportShardBulkAction) until 4.0. Signed-off-by: Michael Froh <[email protected]>
|
❌ Gradle check result for bc9e705: FAILURE Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change? |
|
This PR is stalled because it has been open for 30 days with no activity. |
4 participants
Description
This is consistent with TransportIndexAction and TransportDeleteAction, and ensures that updates behave consistently, whether sent via the
_updateAPI or via the_bulkAPI.Related Issues
Resolves #16980
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.