Wrap fatal TX errors in a new vterrors code

[frouioui]

Description

This Pull Request adds two new vterrors code: VT15001 and VT15002:

• VT15001 is returned to the client when an error happened during a transaction that makes the transaction invalid and unusable. When the primary is shutdown, a PRS happens, or there is a connection loss with the primary, this error will wrap the original error. When this error happens, vtgate will, if applicable, rollback the transaction and clear the session.

• VT09032 is returned after a VT15001 was first issued to the client, to notify the client they need to explicitly send a ROLLBACK to vtgate to acknowledge the fact that their previous transaction is "dead". This is a way to ensure that applications do not keep sending queries, thinking they're in a transaction, even after receiving a VT15001. Once a ROLLBACK is received, VT09032 will not be returned to the client - until a new VT15001 happens.

---

• A new field is added to VTGate sessions' protobuf: error_until_rollback. This field is set to true when we return a VT15001 error to the client, after this, all queries besides ROLLBACK will fail and return VT09032. Once we receive a ROLLBACK we set the field to false. We only set the field to true when doing a "normal" execution, transactional statements (begin, rollback, etc) failing with VT15001 will not set this field to true as there is either no transaction (in the case of begin), or the user is already at the end of the transaction (rollback, commit).

• go/test/endtoend/reparent/newfeaturetest/reparent_in_tx_test.go contains several new E2E tests for the changes made by this PR.

Documentation

• Update error code documentation (#17669) website#1929

Related Issue(s)

• Closes Enable applications to detect stalled connections during PRS #17668

[vitess-bot]

Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• Ensure there is a link to an issue (except for internal cleanup and flaky test fixes), new features should have an RFC that documents use cases and test cases.

Tests

• Bug fixes should have at least one unit or end-to-end test, enhancement and new features should have a sufficient number of tests.

Documentation

• Apply the release notes (needs details) label if users need to know about this change.
• New features should be documented.
• There should be some code comments as to why things are implemented the way they are.
• There should be a comment at the top of each new or modified test to explain what the test does.

New flags

• Is this flag really necessary?
• Flag names must be clear and intuitive, use dashes (-), and have a clear help text.

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow needs to be marked as required, the maintainer team must be notified.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from vitess-operator and arewefastyet, if used there.
• vtctl command output order should be stable and awk-able.

[codecov]

Codecov Report

Attention: Patch coverage is 70.43478% with 34 lines in your changes missing coverage. Please review.

Project coverage is 67.57%. Comparing base (7e24b08) to head (f741e62).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
go/vt/vtgate/plan_execute.go	59.25%	11 Missing ⚠️
go/vt/vterrors/vterrorsgen/main.go	0.00%	10 Missing ⚠️
go/vt/vtgate/executorcontext/safe_session.go	50.00%	4 Missing ⚠️
go/vt/vterrors/code.go	87.50%	2 Missing ⚠️
go/vt/vtgate/executor.go	33.33%	2 Missing ⚠️
go/vt/vtgate/scatter_conn.go	33.33%	2 Missing ⚠️
go/vt/vtgate/tx_conn.go	60.00%	2 Missing ⚠️
go/vt/vttablet/queryservice/wrapped.go	97.67%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #17669      +/-   ##
==========================================
- Coverage   67.59%   67.57%   -0.02%     
==========================================
  Files        1598     1598              
  Lines      259983   260044      +61     
==========================================
  Hits       175727   175727              
- Misses      84256    84317      +61     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[deepthi]

Notes from further offline discussion:

• In order to close the transaction, you have to issue a COMMIT or a ROLLBACK from the client. Because the vtgate-level transaction is effectively pinned to the primary tablets of participating shards, these will also produce errors
• An idea to mitigate these is for us to close the transaction at the vtgate level so that the ROLLBACK becomes a no-op instead of resulting in an error.

We need to spend some more time exploring these options.

[harshit-gangal]

Let's use go/vt/vterrors/constants.go for the magic string

[vitess-bot]

Hello! 👋

This Pull Request is now handled by arewefastyet. The current HEAD and future commits will be benchmarked.

You can find the performance comparison on the arewefastyet website.

[deepthi]

The behavior and tests look good. Most of my suggestions are cosmetic / code reuse etc.

[deepthi]

The error message wording needs some changes. Rest LGTM

[deepthi]

Suggested change

	VT09032 = errorWithoutState("VT09032", vtrpcpb.Code_FAILED_PRECONDITION, "previous transaction failed fatally. Issue a ROLLBACK query to resolve the failure.", "This error occurs after a VT15001 error was sent to the client. Future queries in the same session will continue to fail until the client resolves the issue by sending a ROLLBACK query.")
	VT09032 = errorWithoutState("VT09032", vtrpcpb.Code_FAILED_PRECONDITION, "previous transaction failed. Issue a ROLLBACK to resolve the failure.", "This error occurs after a VT15001 error was sent to the client. Later queries in the same session will continue to fail until the client sends a ROLLBACK.")

[deepthi]

Suggested change

	VT15001 = errorWithNoCode("VT15001", "transaction error, issue ROLLBACK and retry the transaction: %s", "The opened transaction must be ROLLBACK by the application and re-tried.")
	VT15001 = errorWithNoCode("VT15001", "transaction error, issue ROLLBACK and retry the transaction: %s", "Transaction must be rolled back by the application and re-tried.")