feat: surface transaction abort reason on TxnConflictException#290
Open
rahst12 wants to merge 2 commits into
Open
feat: surface transaction abort reason on TxnConflictException#290rahst12 wants to merge 2 commits into
rahst12 wants to merge 2 commits into
Conversation
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.
Problem
When Dgraph aborts a transaction, the Java client collapses every cause into a single
opaque exception:
TxnConflictExceptionexposes no way to tell why the transaction aborted, so anapplication cannot distinguish the cases that warrant different responses:
temporarily blocked, so back off and retry once the move completes;
change); retry with a fresh transaction.
The server now reports the category (see the companion
dgraphPR), encoding it as a"<code>: <detail>"prefix on the gRPCABORTEDstatus description. Without clientsupport, that information is only visible by string-scraping
getMessage().Example
Before, every abort looked the same — there was no way to branch on the cause:
Now the category is available via
getReason(), so callers can respond appropriately:Fix
PreReq: dgraph-io/dgraph#9747
Expose the category as a typed value on
TxnConflictException, parsed from the statusdescription the server already sends.
AbortReasonenum —CONFLICT,PREDICATE_MOVE,STALE_STARTTS,UNKNOWN.TxnConflictException.getReason()— parses the"<code>: <detail>"prefix off thegRPC status and maps it to an
AbortReason. The full human-readable teavailable via
getMessage().Backward compatible by design:
getReason()returnsUNKNOWN, so callers degrade gracefully.getMessage()is unchanged,isRetryable()still returnstrue, and the exceptiontype/hierarchy is unchanged — existing
catchblocks and retry loops are unaffected.Tests
AbortReasonTest— unit tests feeding synthetic gRPCABORTEDstaExceptions.translate, asserting each category parses correctly and that an absent orprefix-less description degrades to
UNKNOWN.AbortReasonLiveTest— cross-language end-to-end test that drives a real(locally patched) Dgraph cluster, forces each abort category, and asserts it propagates
all the way to
getReason(). Skips gracefully when the cluster prerequisites(multi-group for predicate-move, a Zero-restart hook for stale-startts)
configured. A
docker-compose.abort-reason.ymlis included to stand up that cluster.Future work
This change surfaces the category only — the slice the server provide
server enriches aborts with the contended predicate and UID/token (planned
dgraphfollow-up via the gRPC rich-error model, then a first-class
TxnContextfield), thisclient can add typed accessors such as
getConflictPredicates()andgetConflicts()without breaking the
getReason()surface introduced here. A later phase may also expandAbortReason(e.g. splitting non-movepredicate-movecases intoPREDICATE_UNAVAILABLE/
INTERNAL) and revisitisRetryable()for the non-retryable internalcodes already map to
UNKNOWN, so adding values stays backward compatible.Checklist
[Conventional Commits](https://www.conventionalcommits.org/en/v1.0.
with
fix:,feat:,chore:,ci:, etc.