fix(java): ensure waitTask exception propagation#799
Draft
eric-zaharia wants to merge 1 commit into
Draft
Conversation
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 0 |
| Duplication | 0 |
TIP This summary will be updated as you push new changes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Jira ticket: API-473 · Reported by customer in CR-11430
Describe your change
TaskUtils.waitTaskpolls task status in awhile (true)loop and, onInterruptedException/ExecutionExceptionfromgetTask, silentlybreaked out of the loop. BecausewaitTaskreturnsvoid, a swallowed exception was indistinguishable from a genuine"published"confirmation.This PR replaces the silent
breakwith proper exception propagation, mirroring theLaunderThrowablepattern already used throughout the client:InterruptedException→ restore the thread's interrupt flag, then rethrow asAlgoliaRuntimeException.ExecutionException→ unwrap the real cause viaLaunderThrowable.launder, surfacing the underlyingAlgoliaApiException/AlgoliaRetryException/AlgoliaRuntimeException.After the change the loop has only two exits: a real
"published"status (return) or a thrown exception. It can no longer return as if a task completed when it did not.What problem is this fixing?
If
waitTasksilently exited after the copy step (a transient network error, orgetTaskbeing retried on a host that had not yet registered the task),replaceAllObjectsproceeded as though the copy had completed:Result: the main index keeps its records but loses its settings, rules, and synonyms (reset to defaults) — a silent partial wipeout, with no error surfaced to the caller. This is exactly the incident reported in CR-11430.
This bug is unique to the Java v3 (legacy) client — v4 and every other legacy client propagate the exception. v4 is already safe via
TaskUtils.retryUntil(notry/catcharound the supplier) plus areplaceAllObjectscleanup wrapper.