Transaction.commit and Transaction.createReadStream unconditionally retry by invoke Transaction.begin() if any non-ABORTED error is returned; really it should firstly check for error better #2159
Labels
api: spanner
Issues related to the googleapis/nodejs-spanner API.
priority: p2
Moderately-important priority. Fix may not be included in next release.
type: bug
Error or flaw in code with unintended results or allowing sub-optimal usage patterns.
Discovered while implementing tracing for this package that we have this code
nodejs-spanner/src/transaction.ts
Lines 1321 to 1334 in 0342e74
which when interpreted will always invoke Transaction.begin() as long this was the transaction was not previously run aka doesn't have an id and the error returned in .commit() was not ABORTED; but really if we just tried to insert data that already exists and the gRPC backend returns
6 ALREADY_EXISTS: Failed to insert row with primary key ({pk#SingerId:100}) due to previously existing row
we shall ALWAYS try to invoke .begin() which then will again invoke .commit()
Reproducing code
and here is a trace of the problems to confirm visualization
Currently wrong
Expected
I'd classify as a P0 because this adds extra calls and latency to customer calls on the most minor inconvenience like just a typo or data existing
Suggestion
We should only invoke Transaction.begin() on errors that are retryable for example a transient error or a timeout or server unknown internal errors, deadline_exceeded, status_unavailable, resource_exhaused
Kindly /cc-ing @surbhigarg92 @alkatrivedi
The text was updated successfully, but these errors were encountered: