@wtgodbe Are these known failures?

System.Net.Primitives.Unit.Tests.CookieContainerTest.SetCookies_Success

I'm seeing this particular test failure in a few arcade ingestion PRs across 3.1 and 5.0: #28175, dotnet/corefx#43081, dotnet/runtime#53937. I thought it was related to the arcade change, but looks like it's a general failure in the runtime. @Anipik @jeffschwMSFT could somebody take a look? We'll need to get this fixed up before servicing builds kick off on Monday

Adding @danmoseley for System.Net.* test

System.Net.Primitives.Unit.Tests.CookieContainerTest.SetCookies_Success is failing for an amusing reason

We need to roll in dotnet/runtime#53932

I'll create a PR for that in CoreFX.

The regex AV looks very like what dotnet/corefx#43071 should have fixed. (it's being killed on Ubuntu 1804 specifically). That went into corefx release/3.1 a month ago. Is it possible we aren't picking that up?

@jeffschwMSFT there is a failure in Readytorun/DynamicMethodGCStress/DynamicMethodGCStress/DynamicMethodGCStress.sh

@mangod9 can you take a look? https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-coreclr-refs-pull-28177-merge-d04d265aa6084e2082/PayloadGroup0/console.14985ee3.log?sv=2019-07-07&se=2021-06-29T22%3A26%3A21Z&sr=c&sp=rl&sig=NfOsVTOuW0h8vvtRCG7rYj82cZcw2l2ff%2BVABQylUXE%3D

Looks like a timeout

Is it possible we aren't picking that up?

The corefx -> coreclr subscription hasn't fired in a long time since it's a back edge. Should I fire that off? Or is it a shared source thing?

I've no idea - who can answer that? But yes, we should be keeping them up to date, otherwise we're in a nonsensical configuration, testing new CoreCLR with old CoreFX.

Ok, I triggered dotnet/corefx#43083, #28178, and #28179

@wtgodbe can we make those updates happen automatically? I see eg., for the SDK one "Microsoft.NETCore.App: from 3.1.9 to 3.1.17-servicing.21309.1". Presumably it should happen at least monthly.

Looks like a timeout

Yeah feels like its intermittent, trying to rerun it

/azp run

@danmoseley I'd suggest firing them off manually as part of branding - there isn't a day of the month when we know the branches will always be open, so if we create the PRs monthly automatically then they'd sometimes get auto-merged when branches are closed (and we don't want to lose the benefits of having auto-merge on for other maestro PRs)

@wtgodbe there's no way to tell Maestro to not automerge in dotnet/coreclr and dotnet/corefx only?

But if not -- that's OK. if we have another problem, we can kick it then.

there's no way to tell Maestro to not automerge in dotnet/coreclr and dotnet/corefx only?

There is, but then we lose the automatic merging of arcade -> coreclr/corefx & coreclr -> corefx PRs, which could slow down the final builds.

@Anipik, @mmitche is this ready for servicing?