Skip to content

Expose default transient SQL error codes for extensibility #2342

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ankrause opened this issue Feb 5, 2024 · 2 comments
Open

Expose default transient SQL error codes for extensibility #2342

ankrause opened this issue Feb 5, 2024 · 2 comments
Labels
Up-for-Grabs 🙌 Issues that are ready to be picked up for anyone interested. Please self-assign and remove the label

Comments

@ankrause
Copy link

ankrause commented Feb 5, 2024

Is your feature request related to a problem? Please describe.

Currently, the default set of transient error codes is private. This seems to make it difficult to extend error codes without copy/pasting the base set from this repository.

I understand that this field is likely private because it is a modifiable hashset: s_defaultTransientErrors. It would be strange for the consuming code to add values directly to the set which is then used everywhere by default - perhaps unknowingly.

Specifying SqlRetryLogicOption.TransientErrors currently is a total override rather than an add. So, it isn't possible to just add 1 or 2 error codes to the generally accepted pre-defined list.

Describe the solution you'd like

I would like to be able to get a copy of the set and add to it when building a new SqlRetryLogicOption. It doesn't really matter to the consumer how it is exposed as long as the values can be used.

  • Expose property as readonly/immutable type from which a copy can be made.
  • Property/method/etc. that returns a copy of the set.
  • Any other functionally equivalent option.

Describe alternatives you've considered

The only thing I've seen documented so far is a total override (as mentioned above) wherein the consumer just specifies their own codes. Alternatively, the consumer has to copy/paste the core set of transient errors into their own code and then add to it inline. This also means the consumer doesn't get any automatic upgrades if Azure/SqlClient define new transient codes (or re-defines old ones as transient).

@JRahnama JRahnama added the Triage Needed 🆕 For new issues, not triaged yet. label Feb 6, 2024
@kf-gonzalez kf-gonzalez added Up-for-Grabs 🙌 Issues that are ready to be picked up for anyone interested. Please self-assign and remove the label and removed Triage Needed 🆕 For new issues, not triaged yet. labels Feb 6, 2024
@JRahnama
Copy link
Contributor

JRahnama commented Feb 7, 2024

@ankrause we will get back to you on this issue.

@damienhoneyford
Copy link

Please also consider #649 and the associated PR #2127 which also need access to the list of transient error codes to enable the SqlException.IsTransient property to be properly set

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Up-for-Grabs 🙌 Issues that are ready to be picked up for anyone interested. Please self-assign and remove the label
Projects
Status: Ideas for Future
Development

No branches or pull requests

4 participants