Skip to content
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

Expose default transient SQL error codes for extensibility #2342

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 Anyone interested in working on it can ask to be assigned

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 this to Needs triage in SqlClient Triage Board via automation Feb 6, 2024
@kf-gonzalez kf-gonzalez moved this from Needs triage to Ideas for Future in SqlClient Triage Board Feb 6, 2024
@kf-gonzalez kf-gonzalez added 🙌 Up-for-Grabs Anyone interested in working on it can ask to be assigned and removed untriaged labels Feb 6, 2024
@JRahnama
Copy link
Member

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 Anyone interested in working on it can ask to be assigned
Projects
SqlClient Triage Board
  
Ideas for Future
Development

No branches or pull requests

4 participants