Skip to content

Conversation

@cdmihai
Copy link
Contributor

@cdmihai cdmihai commented Jun 16, 2021

Context

Non static graph builds using the project cache didn't set the ProjectInstance on the cache request, leading to crashes in the cache.

Changes Made

Recreate the BuildRequestData for the cache request after the cache service evaluates projects. I was initially using the original BuildSubmission.BuildRequestData which does not contain the project instance.

Testing

Unit tests

Notes

This does not affect non project cache code paths so it shouldn't be a risk for 16.11.

@cdmihai cdmihai changed the title Fix missing project instance Fix missing project instance in project cache requests Jun 16, 2021
Comment on lines +1356 to +1357
// TODO: Reenable when this gets into the main branch.
//[InlineData(true, true)]
Copy link
Member

Choose a reason for hiding this comment

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

When what gets into which main branch?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Literal meaning. When this comment gets into the main branch, the test should be reenabled :)

Copy link
Member

Choose a reason for hiding this comment

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

ah, so there's a fix in our main that's not in our 16.11 that means we should change this on merge?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Correct, the fix is in #6400 which we deemed to risky for 16.11

Copy link
Contributor

@Forgind Forgind left a comment

Choose a reason for hiding this comment

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

LGTM!


return await GetCacheResultAsync(cacheRequest.Submission.BuildRequestData);
return await GetCacheResultAsync(
new BuildRequestData(
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you think it would make sense to check whether the ProjectInstance is set?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good catch, added it.

@Forgind Forgind added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Jun 18, 2021
@AR-May AR-May merged commit 083779f into dotnet:vs16.11 Jun 25, 2021
rokonec pushed a commit that referenced this pull request Aug 5, 2021
* Fix missing project instance in project cache requests (#6568)

Context
Non static graph builds using the project cache didn't set the ProjectInstance on the cache request, leading to crashes in the cache.

Changes Made
Recreate the BuildRequestData for the cache request after the cache service evaluates projects. I was initially using the original BuildSubmission.BuildRequestData which does not contain the project instance.

* Don't launch debugger window for all tests

* Convert static InitializePlugin into non-static BeginBuildAsync

To allow asserting service state transition

* Assert state transitions in ProjectCacheService

* Only initialize once for the VS workaround

* Bravely set DoNotLaunchDebugger only once for all tests

* Simplify branching

* [vs16.11] Update dependencies from dotnet/arcade (#6625)

* Update dependencies from https://github.com/dotnet/arcade build 20210628.3

Microsoft.DotNet.Arcade.Sdk
 From Version 5.0.0-beta.21315.2 -> To Version 5.0.0-beta.21328.3

* Don't schedule proxy builds to inproc node if their configs previously built on oop nodes (#6635)

Fixes a bug in proxy build scheduling introduced by #6386. If a the BuildRequestConfiguration associated with a proxy request has been built before on an out of proc (oop) node then the scheduler will fail with either one of:
- affinity mismatch error. This happens when the proxy build is assigned to the inproc (inp) node but its configuration is already assigned to an oop node `AND` serving other existing requests, either blocked or running.
- unscheduled requests remain even if there's free oop nodes that can serve them. This happens (as far as I can tell) when the proxy's configuration is already assigned to an oop node (because a previously built non proxy request was assigned there) `AND` there's no other existing requests for that configuration

The fix in this PR is to not assign a proxy build to the inproc node if its configuration was previously assigned to another node.

* Localized file check-in by OneLocBuild Task (#6644)

* 16.11 Final Branding (#6656)

Co-authored-by: Rainer Sigwald <[email protected]>

Co-authored-by: Mihai Codoban <[email protected]>
Co-authored-by: AR-May <[email protected]>
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: dotnet bot <[email protected]>
Co-authored-by: Ben Villalobos <[email protected]>
Co-authored-by: Rainer Sigwald <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants