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

Fix concurrency/consistency issues in Gallery API push #6600

Merged
merged 2 commits into from
Oct 30, 2018

Conversation

shishirx34
Copy link
Contributor

Fixes https://github.com/NuGet/Engineering/issues/1817. Mostly affects the functional test failures, kind of hard to test but I will deploy this change to dev and run functional tests couple of times to verify.

@shishirx34 shishirx34 changed the title Fix concurrency issues in Gallery API push Fix concurrency/consistency issues in Gallery API push Oct 26, 2018
@joelverhagen
Copy link
Member

        var package = packageRegistration.Packages.SingleOrDefault(pv => pv.Version == packageMetadata.Version.OriginalVersion);

I don't understand why we even need this line. Isn't this checked at the beginning of the control and again (by the DB) on commit?

Said another way, we already check it in memory here:

return new HttpStatusCodeWithBodyResult(
HttpStatusCode.Conflict,
string.Format(CultureInfo.CurrentCulture, Strings.PackageExistsAndCannotBeModified,
id, version.ToNormalizedStringSafe()));

And the DB check it with a unique constraint on (PackageRegistrationKey, NormalizedVersion) on the packages table. What does this one add?


Refers to: src/NuGetGallery/Services/PackageService.cs:478 in bee9def. [](commit_id = bee9def, deletion_comment = False)

Copy link
Member

@joelverhagen joelverhagen left a comment

Choose a reason for hiding this comment

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

🕐

@shishirx34
Copy link
Contributor Author

@joelverhagen - technically we do not check for the conflict on DB commit, rather in the CommitPackageAsync we check if the file exists in validation container in which case we return a Conflict. But even before that we queue up the validation into the pipeline(which eventually will deadletter or thrown away). If StartValidationAsync were to mark package as available then on DB commit unique constraint will still throw an EntityException which we could possibly handle(not handled in the code today) to return conflict(that could be another approach).

public async Task<PackageCommitResult> CommitPackageAsync(Package package, Stream packageFile)

I do not see any harm in handling it the current way in PR, given that it could avoid unnecessary queuing of validations and the check doesn't result in any performance issues(fail fast).

@shishirx34
Copy link
Contributor Author

I added the concurrency and sql constraint violations check for completion.

@shishirx34 shishirx34 merged commit 6ebb7a2 into dev Oct 30, 2018
@joelverhagen joelverhagen deleted the fix-push-concurrency branch July 1, 2019 22:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants