Test failure: CanExternalSignIn

[ryanbrandenburg]

This test fails occasionally with the following error:

System.NullReferenceException : Object reference not set to an instance of an object.
   at System.Collections.Generic.Dictionary`2.FindEntry(TKey key)
   at System.Collections.Generic.Dictionary`2.TryGetValue(TKey key, TValue& value)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
   at Castle.DynamicProxy.ProxyGenerator.CreateClassProxy(Type classToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, Object[] constructorArguments, IInterceptor[] interceptors)
   at Moq.Proxy.CastleProxyFactory.CreateProxy(Type mockType, ICallInterceptor interceptor, Type[] interfaces, Object[] arguments)
   at Moq.Mock`1.<InitializeInstance>b__20_0()
   at Moq.Mock`1.OnGetObject()
   at Moq.Mock`1.get_Object()
   at Microsoft.AspNetCore.Identity.Test.MockHelpers.MockUserManager[TUser]() in /_/test/Shared/MockHelpers.cs:line 22
   at Microsoft.AspNetCore.Identity.Test.SignInManagerTest.SetupUserManager(PocoUser user)
   at Microsoft.AspNetCore.Identity.Test.SignInManagerTest.CanExternalSignIn(Boolean isPersistent, Boolean supportsLockout) in /_/test/Identity.Test/SignInManagerTest.cs:line 523
--- End of stack trace from previous location where exception was thrown ---

Other tests within that build may have failed with a similar message, but they are not listed here. Check the link above for more info.

CC @Eilon,@muratg,@mkArtakMSFT

This issue was made automatically. If there is a problem contact @ryanbrandenburg.

[ryanbrandenburg]

Please use this workflow to address this flaky test issue, including checking applicable checkboxes and filling in the applicable "TODO" entries:

• Is this actually a flaky test?

  • No, this is a regular test failure, fix the test/product (TODO: Link to commit/PR)
  • Yes, proceed below...

• Is this test failure caused by product code flakiness? (Either this product, or another product this test depends on.)

  • [x] File a bug against the product (https://github.com/moq/moq4/issues/653)
  • Is it possible to change the test to avoid the flakiness?
  • Yes? Go to the "Change the test!" section.
  • No?
    • [ ] Disable the test (TODO: Link to PR/commit)
    • [ ] Wait for other bug to be resolved
    • [ ] Wait for us to get build that has the fix
    • [ ] Re-enable our test (TODO: Link to PR/commit)
    • [ ] Close this bug

• Is it that the test itself is flaky? This includes external transient problems (e.g. remote server problems, file system race condition, etc.)

  • Is there is a way to change our test to avoid this flakiness?
  • Yes? Change the test!
    • [ ] Change the test to avoid the flakiness, for example by using a different test strategy, or by adding retries w/ timeouts (TODO: Link to PR/commit)
    • [ ] Run the test 100 times locally as a sanity check.
    • [ ] Close this bug
  • No?
    • [ ] Delete the test because flaky tests are not useful (TODO: Link to PR/commit)

This comment was made automatically. If there is a problem contact @ryanbrandenburg.

[HaoK]

@ryanbrandenburg which branch of the if statement would this go if it appears to be Moq itself being flaky here. This is failing inside of this, there's basically nothing going on here

            var store = new Mock<IUserStore<TUser>>();
            var mgr = new Mock<UserManager<TUser>>(store.Object, null, null, null, null, null, null, null, null);

[ryanbrandenburg]

That would be either

No, this is a regular test failure, fix the test/product (TODO: Link to commit/PR)

or

Is this test failure caused by product code flakiness? (Either this product, or another product this test depends on.)

depending on if it's flaky or not.

[HaoK]

Ok filed an issue with moq, do I leave this open or close this bug as external?

[HaoK]

Recommendation from moq is that we upgrade to 4.9 which might fix this issue.

[ryanbrandenburg]

Leave this bug open to track the external issue. Also because otherwise the bot will open one identical to it the next time it fails.

[ryanbrandenburg]

EnsureClaimsIdentityHasExpectedClaims failed with about the same error on master.

This comment was made automatically. If there is a problem contact ryanbrandenburg.

[HaoK]

@natemcmaster I verified that identity seems fine when bumping up my local dependencies.props version of moq to 4.9.0.

Should I submit a PR to universe bumping up the version here https://github.com/aspnet/Universe/blob/master/build/dependencies.props#L126 ? Or is there some other steps that also are needed to upgrade moq to 4.9.0?

[natemcmaster]

yes, submit a PR to Universe. We'll probably run a build with this change first to make sure Moq 4.9 still works on our many other test projects.

[HaoK]

Ok https://github.com/aspnet/Universe/pull/1350