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

Improve batch error handling #16121

Merged
merged 4 commits into from
Oct 21, 2020

Conversation

christothes
Copy link
Member

closes #16091

@christothes christothes self-assigned this Oct 20, 2020
@ghost ghost added the Tables label Oct 20, 2020
@christothes christothes added the Client This issue points to a problem in the data-plane of the library. label Oct 20, 2020
/// The <see cref="ITableEntity"/> related to the batch operation error.
/// </summary>
/// <value></value>
public ITableEntity TableEntity { get; }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would this be used?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's mostly a convenient way to get a reference to the entity that triggered the error in a batch. Scenarios I can imagine would be that they want to just inspect which row key was the problem, or casting it to the full type of their entity model to modify it and send in a new batch.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be the first service-specific exception type we ship. So I'd like to make sure we really have the use-case for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use the Data property of RequestFailedException for this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hadn't looked at that. Let me see if that would work.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be cool but wouldn't we have to support a lot of error message manipulation code if we go that route?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

True - that could be a pain to manage.

I like the new exception type best. Is there a concern with it other than it being rare?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's rare because most of the scenario that we intended to support with a new exception was very niche and not worth expanding the exception hierarchy. @KrzysztofCwalina is a large proponent of having as few exception types as possible.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I see the value of putting it in Data without a direct and obvious way to fetch it.

Can we say in the message that Data["TableEntity"] contains the entity that failed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussed a bit offline. We'll add some additional context to the message containing the RowKey of the entity causing the failure. If we get additional feedback that this is not sufficient, we'll reevaluate.

//Get the failed index
var match = s_entityIndexRegex.Match(ex.Message);

if (match.Success && int.TryParse(match.Groups["index"].Value, out int failedEntityIndex))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can multiple entities fail?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No - the first one that causes a problem fails the whole batch.

@@ -19,6 +21,7 @@ internal partial class TableRestClient
internal ClientDiagnostics clientDiagnostics => _clientDiagnostics;
internal string endpoint => url;
internal string clientVersion => version;
private static readonly Regex s_entityIndexRegex = new Regex(@"""value"":""(?<index>[\d]+):", RegexOptions.Compiled);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we parse JSON instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In this case it would only get me closer to the value property which I'd then have to parse with SubString. Do you see other benefits?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I didn't realize that the property itself isn't just the index.

@christothes christothes merged commit 834b0f9 into Azure:master Oct 21, 2020
annelo-msft pushed a commit to annelo-msft/azure-sdk-for-net that referenced this pull request Feb 17, 2021
* Improve batch error handling
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Client This issue points to a problem in the data-plane of the library. Tables
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create custom exception for batch errors that contains the entity that caused the exception
2 participants