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

[release/9.0-rc2] Fix Random.GetItems breaking change in produced sequence #108018

Merged
merged 1 commit into from
Sep 19, 2024

Conversation

github-actions[bot]
Copy link
Contributor

@github-actions github-actions bot commented Sep 19, 2024

Backport of #108017 to release/9.0-rc2

/cc @stephentoub

Customer Impact

  • Customer reported
  • Found internally

#92229 added a special-case to optimize Random.GetItems in certain common situations. That, however, ends up observably changing the sequence of values the Random instance produces. If the Random instance was just constructed as new Random() or Random.Shared, there's no reasonable way for a developer to have taken a dependency on the sequence. But if the instance was constructed with a seed, e.g. new Random(42), or if a custom derived type was used, the change is observable, yielding a different sequence of values than previously was produced. Such seeded instances are typically used when it's important that the same sequence always be produced, such as in tests. This fix adds an additional guard clause so that the optimization only kicks in for the cases where it's not observable.

Regression

  • Yes
  • No

#92229

Testing

Validated that the same sequence produced before is now produced, and also that .NET 8 performance isn't regressed.

Risk

Low. It just means that we no longer employ the .NET 9 optimization in some cases we previously employed it.

Developers, often in tests, rely on seeded Random instances producing the same sequence of values on every use. We made a change in .NET 9, though, that changed the sequence GetItems produces, due to employing a different algorithm. This fixes that special-case to only be used when the developer couldn't rely on the results being deterministic, namely when using either `new Random()` or `Random.Shared`. If a seed is provided or if a custom derived implementation is used, it falls back to the old behavior.
@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Sep 19, 2024
@stephentoub stephentoub added area-System.Runtime and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Sep 19, 2024
@stephentoub stephentoub added this to the 9.0.0 milestone Sep 19, 2024
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-runtime
See info in area-owners.md if you want to be subscribed.

@stephentoub stephentoub added the Servicing-consider Issue for next servicing release review label Sep 19, 2024
@stephentoub stephentoub changed the title [release/9.0-rc2] Fix Random.GetItems observably breaking change in produced sequence [release/9.0-rc2] Fix Random.GetItems breaking change in produced sequence Sep 19, 2024
@rbhanda rbhanda added Servicing-approved Approved for servicing release and removed Servicing-consider Issue for next servicing release review labels Sep 19, 2024
Copy link
Member

@carlossanlop carlossanlop left a comment

Choose a reason for hiding this comment

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

Approved in Tactics

@carlossanlop carlossanlop merged commit fe77f43 into release/9.0-rc2 Sep 19, 2024
149 of 156 checks passed
@carlossanlop carlossanlop deleted the backport/pr-108017-to-release/9.0-rc2 branch September 19, 2024 18:07
@github-actions github-actions bot locked and limited conversation to collaborators Oct 20, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Runtime Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants