Coverlet fails to write coverage with file locked error

So this is a bit odd, but it only happens during our CI (and it is intermittent). We're using v1.2 of the vstest collector.
The error we get is this:
Data collector 'XPlat code coverage' message: [coverlet]Coverlet.Collector.Utilities.CoverletDataCollectorException: CoverletCoverageDataCollector: Failed to get coverage result
 ---> System.IO.IOException: The process cannot access the file '/tmp/MySourceProject_8b9f64e1-2aa6-4144-aece-e1ec4323d842' because it is being used by another process.
   at System.IO.FileStream.Init(FileMode mode, FileShare share, String originalPath)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at Coverlet.Core.Helpers.FileSystem.NewFileStream(String path, FileMode mode) in D:\git\coverletToRelease\src\coverlet.core\Helpers\FileSystem.cs:line 43
   at Coverlet.Core.Coverage.CalculateCoverage() in D:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 352
   at Coverlet.Core.Coverage.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 137
   at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage) in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageWrapper.cs:line 44
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 91
   --- End of inner exception stack trace ---
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 96
   at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e) in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverletCoverageCollector.cs:line 148.

What is strange is that after this error message, we see the last test case complete (we use the normal logging verbosity so we see every test case printed). We're using .net core 3.1, and xunit 2.4.1 if it matters (we use a xunit collection fixture too). It appears that the collection fixture is disposed before the last test's results are printed whether coverlet succeeds or not, so I'm thinking the last test being printed out after the coverlet error is not an indication that it is actually running after coverlet is blocked.
Some other interesting info about our builds: It is in a docker container, with the test results directory mounted on a volume, so I can't imagine another process is stepping on any file being used here. We pass a filter into dotnet test because we have a number of expensive tests that we run in parallel by running multiple docker containers with different filters simultaneously.
When running 16.4.0 of the test sdk, we'd often see the error manifest as:
Data collector 'XPlat code coverage' message: [coverlet]Coverlet.Collector.Utilities.CoverletDataCollectorException: CoverletCoverageDataCollector: Failed to get coverage result
 ---> System.IO.EndOfStreamException: Unable to read beyond the end of the stream.
   at System.IO.BinaryReader.InternalRead(Int32 numBytes)
   at Coverlet.Core.Coverage.CalculateCoverage() in D:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 363
   at Coverlet.Core.Coverage.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 137
   at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage) in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageWrapper.cs:line 44
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 91
   --- End of inner exception stack trace ---
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 96
   at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e) in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverletCoverageCollector.cs:line 148.

But I'm only seeing the first error I posted with 16.5.0.

Hi Andrew, some notes

When running 16.4.0 of the test sdk, we'd often see the error manifest as:

It's ok and expected, until sdk 16.5.0 there was a bug inside vstest and coverlet collection greater than 1.0.0 weren't loaded  https://github.com/tonerdo/coverlet/blob/master/Documentation/KnowIssues.md#2-upgrade-coverletcollector-to-version--100
So here you're hitting the above issue.

The process cannot access the file

Are you running test on solution file(or repo root) or are you running dotnet test on every test project?If you're running from sln can you try with one dotnet test for every test csproj?
I saw this issue another time on big solutions where for some reason parallel tests locked hit file, as if the same instrumented lib was used in different process and so same file is used https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Instrumentation/Instrumenter.cs#L239

I'm running it on the csproj file directly with this command:
dotnet test ./MyTestProject/MyTestProject.csproj --configuration Release --no-build -v n --collect:"XPlat Code Coverage" --settings coverlet.runsettings --filter "Feature=Foo"

I then have various test classes that use xunit traits:
[Trait("Feature", "Foo")]
public class SomeFeature { ... }

Also, I forgot to mention, I pass it this runsettings file:
<?xml version="1.0" encoding="utf-8" ?>
<RunSettings>
  <DataCollectionRunSettings>
    <DataCollectors>
      <DataCollector friendlyName="XPlat code coverage">
        <Configuration>
          <Format>lcov</Format>
          <Exclude>[xunit*]*</Exclude>
          <ExcludeByFile>/app/gen/Namely.*.Grpc/*</ExcludeByFile>
        </Configuration>
      </DataCollector>
    </DataCollectors>
  </DataCollectionRunSettings>
</RunSettings>

I'm currently trying to create a repro case, but am struggling. One thing I'm noticing in my real project is that this is logged before the last test's result (whether coverlet fails or not):
[xUnit.net 00:06:54.88]   Finished:    MyTestProject

And it gets slightly more frustrating: I witnessed a test run fail to generate coverage with the same error on one of my projects that does not use filters or xunit fixtures/collections, but otherwise the setup is identical: running in docker, using latest coverlet + .net sdk + xunit.

So interestingly, I'm now consistently getting the failure for a specific set of filters - If I run this locally within a docker-compose, I get the same issue. I thought it might be the parallel containers' volume mounts somehow stepping on each other, but I see the error even when this is the only container executing. I'll continue to try to repro this in a shareable manner.

Does it happen out of container?

Another test we can do, can you generate logs using --diag:log.txt https://github.com/tonerdo/coverlet/blob/master/Documentation/Troubleshooting.md#collectors-integration

I haven't witnessed it outside the container. I'll generate the logs and report back.

@MarcoRossignoli thank you for your help on this! I think I found the culprit:
 System.IO.IOException : The configured user limit (128) on the number of inotify instances has been reached, or the per-process limit on the number of open file descriptors has been reached.

So we were using the default asp.net host (and running tests against the test server). This by default adds 2 watched json files for the application configuration. By taking full control of the host being built, I was able to at least intermittently get the coverage working again.
This is seemingly a race condition between xunit parallelized collections - on my PC that I've given more resources to docker, I was getting test failures with the above error also. So it seems like the file handles opened by asp.net were hitting a limit, and we were lucky it wasn't failing tests also in our CI.

Was on logs that message?

They were... but sadly I hard deleted the logs as I was trying to investigate my issue.
I've updated how we create the config to not watch the json files, and I'm still seeing the original hits file error in another filtered project, but not the user limit error.

but not the user limit error.

Some other strange infos from logs?

I didn't see anything obviously wrong, but here is the the collector logs:
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.565,<PHONE_NUMBER>5418, datacollector.dll, DataCollectorMain.Run: Starting data collector run with args: --port,46037,--parentprocessid,48,--diag,/app/coverletlogs/log-paychecks.datacollector.20-02-20_06-07-53_48147_4.txt,--tracelevel,4
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.577,<PHONE_NUMBER>6944, datacollector.dll, DataCollector: Monitoring parent process with id: '48'
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.599,<PHONE_NUMBER>6128, datacollector.dll, Trying to connect to server on socket : <IP_ADDRESS>:46037
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.612,<PHONE_NUMBER>9720, datacollector.dll, SocketCommunicationManager : SetupClientAsync : Attempting to connect to the server.
TpTrace Information: 0 : 61, 5, 2020/02/20, 06:07:53.626,<PHONE_NUMBER>7895, datacollector.dll, Connected to the server successfully
TpTrace Information: 0 : 61, 5, 2020/02/20, 06:07:53.627,<PHONE_NUMBER>0304, datacollector.dll, Using the buffer size of 16384 bytes
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.714,<PHONE_NUMBER>3607, datacollector.dll, DataCollector: Start Request Processing.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.720,<PHONE_NUMBER>2990, datacollector.dll, DataCollectionRequestHandler.ProcessRequests : Datacollector received message: (DataCollection.BeforeTestRunStart) -> {
  "SettingsXml": "<RunSettings><DataCollectionRunSettings><DataCollectors><DataCollector friendlyName=\"XPlat code coverage\" enabled=\"True\"><Configuration><Format>lcov</Format><Exclude>[xunit*]*</Exclude><ExcludeByFile>/app/gen/Namely.*.Grpc/*</ExcludeByFile></Configuration></DataCollector></DataCollectors></DataCollectionRunSettings><RunSettingsDirectory>/app/test</RunSettingsDirectory><RunConfiguration><ResultsDirectory>/coverage/paychecks</ResultsDirectory><TargetPlatform>X64</TargetPlatform><TargetFrameworkVersion>.NETCoreApp,Version=v3.1</TargetFrameworkVersion><TestAdaptersPaths>/root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/;/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/;/usr/share/dotnet/sdk/3.1.102/Extensions</TestAdaptersPaths><DesignMode>False</DesignMode><CollectSourceInformation>False</CollectSourceInformation></RunConfiguration><InProcDataCollectionRunSettings><InProcDataCollectors><InProcDataCollector assemblyQualifiedName=\"Coverlet.Collector.DataCollection.CoverletInProcDataCollector, coverlet.collector, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=null\" friendlyName=\"XPlat Code Coverage\" enabled=\"True\" codebase=\"coverlet.collector.dll\" /></InProcDataCollectors></InProcDataCollectionRunSettings><LoggerRunSettings><Loggers><Logger friendlyName=\"Console\" assemblyQualifiedName=\"Microsoft.VisualStudio.TestPlatform.CommandLine.Internal.ConsoleLogger, vstest.console, Version=<IP_ADDRESS>, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a\" codeBase=\"/usr/share/dotnet/sdk/3.1.102/vstest.console.dll\" enabled=\"True\"><Configuration><Verbosity>normal</Verbosity></Configuration></Logger></Loggers></LoggerRunSettings></RunSettings>",
  "Sources": [
    "/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Api.Test.dll"
  ]
}
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.835,<PHONE_NUMBER>3678, datacollector.dll, TestPluginCache: Update extensions started. Skip filter = False
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.837,<PHONE_NUMBER>5811, datacollector.dll, TestPluginCache: Using directories for assembly resolution '/root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0,/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0,/usr/share/dotnet/sdk/3.1.102/Extensions'.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.838,<PHONE_NUMBER>9053, datacollector.dll, TestPluginCache: Updated the available extensions to '/root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.collector.dll,/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/Microsoft.VisualStudio.TraceDataCollector.dll,/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.BlameDataCollector.dll,/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.EventLogCollector.dll'.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.857,<PHONE_NUMBER>6204, datacollector.dll, TestPluginCache.DiscoverTestExtensions: finding test extensions in assemblies endswith: Collector.dll TPluginInfo: Microsoft.VisualStudio.TestPlatform.Common.DataCollector.DataCollectorConfig TExtension: Microsoft.VisualStudio.TestPlatform.ObjectModel.DataCollection.DataCollector
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.858,<PHONE_NUMBER>6029, datacollector.dll, TestPluginCache.GetExtensionPaths: Filtered extension paths: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.collector.dll
/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/Microsoft.VisualStudio.TraceDataCollector.dll
/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.BlameDataCollector.dll
/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.EventLogCollector.dll
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.859,<PHONE_NUMBER>4479, datacollector.dll, TestPluginCache.GetExtensionPaths: Added default extension paths:
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.860,<PHONE_NUMBER>4070, datacollector.dll, TestPluginCache.GetExtensionPaths: Added unfilterableExtensionPaths:
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.861,<PHONE_NUMBER>7070, datacollector.dll, AssemblyResolver.ctor: Creating AssemblyResolver with searchDirectories /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0,/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0,/usr/share/dotnet/sdk/3.1.102/Extensions,/usr/share/dotnet/sdk/3.1.102
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.863,<PHONE_NUMBER>7704, datacollector.dll, TestPluginCache.DiscoverTestExtensions: Discovering the extensions using extension path.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.864,<PHONE_NUMBER>3879, datacollector.dll, TestPluginCache.GetExtensionPaths: Filtered extension paths: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.collector.dll
/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/Microsoft.VisualStudio.TraceDataCollector.dll
/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.BlameDataCollector.dll
/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.EventLogCollector.dll
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.865,<PHONE_NUMBER>4496, datacollector.dll, TestPluginCache.GetExtensionPaths: Added default extension paths:
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.865,<PHONE_NUMBER>6837, datacollector.dll, TestPluginCache.GetExtensionPaths: Added unfilterableExtensionPaths:
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.866,<PHONE_NUMBER>6062, datacollector.dll, TestPluginCache.DiscoverTestExtensions: Discovering the extensions using allExtensionPaths: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.collector.dll
/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/Microsoft.VisualStudio.TraceDataCollector.dll
/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.BlameDataCollector.dll
/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.EventLogCollector.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.867,<PHONE_NUMBER>2646, datacollector.dll, AssemblyResolver.AddSearchDirectories: Adding more searchDirectories /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0,/usr/share/dotnet/sdk/3.1.102
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.868,<PHONE_NUMBER>0729, datacollector.dll, AssemblyResolver.AddSearchDirectories: Adding more searchDirectories /root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0,/usr/share/dotnet/sdk/3.1.102
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.869,<PHONE_NUMBER>6537, datacollector.dll, AssemblyResolver.AddSearchDirectories: Adding more searchDirectories /usr/share/dotnet/sdk/3.1.102/Extensions,/usr/share/dotnet/sdk/3.1.102
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.870,<PHONE_NUMBER>7929, datacollector.dll, AssemblyResolver.AddSearchDirectories: Adding more searchDirectories /usr/share/dotnet/sdk/3.1.102/Extensions,/usr/share/dotnet/sdk/3.1.102
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.871,<PHONE_NUMBER>3554, datacollector.dll, AssemblyResolver.OnResolve: coverlet.collector: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.872,<PHONE_NUMBER>3487, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: coverlet.collector, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.collector.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.873,<PHONE_NUMBER>3413, datacollector.dll, AssemblyResolver.OnResolve: coverlet.core: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.875,<PHONE_NUMBER>1221, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: coverlet.core, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.core.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.877,<PHONE_NUMBER>8604, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.VisualStudio.TraceDataCollector: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.878,<PHONE_NUMBER>5521, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.VisualStudio.TraceDataCollector, from path: /root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/Microsoft.VisualStudio.TraceDataCollector.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.880,<PHONE_NUMBER>6171, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.TestPlatform.Extensions.BlameDataCollector: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.882,<PHONE_NUMBER>5638, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.TestPlatform.Extensions.BlameDataCollector, from path: /usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.BlameDataCollector.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.883,<PHONE_NUMBER>2613, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.TestPlatform.Extensions.EventLogCollector: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.884,<PHONE_NUMBER>7821, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.TestPlatform.Extensions.EventLogCollector, from path: /usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.EventLogCollector.dll
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.886,<PHONE_NUMBER>7021, datacollector.dll, TestPluginCache: Discovered the extensions using extension path '/root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/coverlet.collector.dll,/root/.nuget/packages/microsoft.codecoverage/16.5.0/build/netstandard1.0/Microsoft.VisualStudio.TraceDataCollector.dll,/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.BlameDataCollector.dll,/usr/share/dotnet/sdk/3.1.102/Extensions/Microsoft.TestPlatform.Extensions.EventLogCollector.dll'.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.887,<PHONE_NUMBER>9930, datacollector.dll, TestPluginCache: Discoverers are ''.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.888,<PHONE_NUMBER>5830, datacollector.dll, TestPluginCache: Executors are ''.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.889,<PHONE_NUMBER>4021, datacollector.dll, TestPluginCache: Setting providers are ''.
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.890,<PHONE_NUMBER>4830, datacollector.dll, TestPluginCache: Loggers are ''.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.893,<PHONE_NUMBER>1822, datacollector.dll, TestPluginManager.CreateTestExtension: Attempting to load test extension: Coverlet.Collector.DataCollection.CoverletCoverageCollector
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.898,<PHONE_NUMBER>7863, datacollector.dll, [coverlet]Initializing CoverletCoverageDataCollector with configuration: '<Configuration><Format>lcov</Format><Exclude>[xunit*]*</Exclude><ExcludeByFile>/app/gen/Namely.*.Grpc/*</ExcludeByFile><Framework>.NETCoreApp,Version=v3.1</Framework></Configuration>'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.900,<PHONE_NUMBER>2430, datacollector.dll, [coverlet]CoverletCoverageDataCollector: SessionStart received
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.901,<PHONE_NUMBER>8239, datacollector.dll, [coverlet]CoverletCoverageDataCollector: TestModules: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Api.Test.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.906,<PHONE_NUMBER>9455, datacollector.dll, [coverlet]CoverletCoverageDataCollector: Initializing coverlet process with settings: "TestModule: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Api.Test.dll', IncludeFilters: '', IncludeDirectories: '', ExcludeFilters: '[coverlet.*]*,[xunit*]*', ExcludeSourceFiles: '/app/gen/Namely.*.Grpc/*', ExcludeAttributes: '', MergeWith: '', UseSourceLink: 'False'SingleHit: 'False'IncludeTestAssembly: 'False'"
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.909,<PHONE_NUMBER>9980, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.Extensions.DependencyInjection: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.910,<PHONE_NUMBER>9581, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.Extensions.DependencyInjection, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/Microsoft.Extensions.DependencyInjection.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.911,<PHONE_NUMBER>6522, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.Extensions.DependencyInjection.Abstractions: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.912,<PHONE_NUMBER>8322, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.Extensions.DependencyInjection.Abstractions, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/Microsoft.Extensions.DependencyInjection.Abstractions.dll
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.958,<PHONE_NUMBER>3007, datacollector.dll, [coverlet]Excluded module filter '[coverlet.*]*'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.959,<PHONE_NUMBER>1157, datacollector.dll, [coverlet]Excluded module filter '[xunit*]*'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.960,<PHONE_NUMBER>2416, datacollector.dll, [coverlet]Excluded source files filter '/app/gen/Namely.*.Grpc/*'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.971,<PHONE_NUMBER>6058, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.assert.dll'
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.973,<PHONE_NUMBER>7508, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.Extensions.FileSystemGlobbing: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:53.975,<PHONE_NUMBER>9466, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.Extensions.FileSystemGlobbing, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/Microsoft.Extensions.FileSystemGlobbing.dll
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:53.999,<PHONE_NUMBER>6409, datacollector.dll, [coverlet]Unable to instrument module: /app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/Humanizer.dll, embedded pdb without local source files, [d:\a\1\s\src\Humanizer\obj\Release\netstandard2.0\Humanizer.Version.cs]
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:54.000,<PHONE_NUMBER>2792, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.runner.utility.netcoreapp10.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:54.002,<PHONE_NUMBER>4309, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.abstractions.dll'
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:54.011,<PHONE_NUMBER>3643, datacollector.dll, AssemblyResolver.OnResolve: Mono.Cecil: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:54.012,<PHONE_NUMBER>6801, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Mono.Cecil, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/Mono.Cecil.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:54.033,<PHONE_NUMBER>7277, datacollector.dll, AssemblyResolver.OnResolve: Microsoft.Extensions.DependencyModel: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:54.035,<PHONE_NUMBER>3135, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Microsoft.Extensions.DependencyModel, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/Microsoft.Extensions.DependencyModel.dll
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:54.143,<PHONE_NUMBER>9439, datacollector.dll, AssemblyResolver.OnResolve: Mono.Cecil.Rocks: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:54.145,<PHONE_NUMBER>0397, datacollector.dll, AssemblyResolver.OnResolve: Resolved assembly: Mono.Cecil.Rocks, from path: /root/.nuget/packages/coverlet.collector/1.2.0/build/netstandard1.0/Mono.Cecil.Rocks.dll
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.165,<PHONE_NUMBER>4945, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Uploads.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.167,<PHONE_NUMBER>6370, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.TaxParams.Grpc/TaxParamsGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.167,<PHONE_NUMBER>3320, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Releaseflags.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.168,<PHONE_NUMBER>5412, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Proration.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.169,<PHONE_NUMBER>4287, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.PdfFormGeneration.Grpc/PdfFormGenerationGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.169,<PHONE_NUMBER>4921, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.PayrollProcessingDispatcher.Grpc/PayrollProcessingDispatcherGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.170,<PHONE_NUMBER>4479, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Payroll.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.171,<PHONE_NUMBER>4329, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Hcm.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.171,<PHONE_NUMBER>1621, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Employment.Grpc/EmploymentReaderServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.172,<PHONE_NUMBER>9479, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Employment.Grpc/EmploymentWriterServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.173,<PHONE_NUMBER>9229, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Compensation.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.173,<PHONE_NUMBER>6062, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Companies.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.174,<PHONE_NUMBER>5496, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.AddressValidator.Grpc/AddressValidatorGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.174,<PHONE_NUMBER>7571, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Address.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.175,<PHONE_NUMBER>7637, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Deductions.Grpc/DeductionsGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.176,<PHONE_NUMBER>4621, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.Paycycles.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.177,<PHONE_NUMBER>6554, datacollector.dll, [coverlet]Excluded source file: '/app/gen/Namely.PayCyclesConfiguration.Grpc/ServiceGrpc.cs'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.177,<PHONE_NUMBER>0412, datacollector.dll, [coverlet]Instrumented module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Core.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.180,<PHONE_NUMBER>4113, datacollector.dll, [coverlet]Unable to instrument module: /app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/Pipelines.Sockets.Unofficial.dll, embedded pdb without local source files, [C:\Code\Pipelines.Sockets.Unofficial\src\Pipelines.Sockets.Unofficial\ConnectionAbortedException.cs]
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.182,<PHONE_NUMBER>6921, datacollector.dll, [coverlet]Unable to instrument module: /app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/Dapper.dll, embedded pdb without local source files, [C:\projects\dapper\Dapper\obj\Release\netstandard2.0\Dapper.Version.cs]
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.211,<PHONE_NUMBER>5814, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.execution.dotnet.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.212,<PHONE_NUMBER>1772, datacollector.dll, [coverlet]Unable to instrument module: /app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/System.Interactive.Async.dll, embedded pdb without local source files, [D:\a\1\s\Ix.NET\Source\System.Interactive.Async\TaskExt.cs]
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.213,<PHONE_NUMBER>0430, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.runner.reporters.netcoreapp10.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.214,<PHONE_NUMBER>7247, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.core.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.218,<PHONE_NUMBER>4881, datacollector.dll, [coverlet]Unable to instrument module: /app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/StackExchange.Redis.dll, embedded pdb without local source files, [C:\projects\stackexchange-redis\src\StackExchange.Redis\BufferReader.cs]
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:56.219,<PHONE_NUMBER>4131, datacollector.dll, [coverlet]Excluded module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/xunit.runner.visualstudio.dotnetcore.testadapter.dll'
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:07:57.093,<PHONE_NUMBER>9587, datacollector.dll, [coverlet]Instrumented module: '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/Namely.PayCyclesConfiguration.Shared.dll'
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:57.101,<PHONE_NUMBER>8779, datacollector.dll, DataCollectionRequestHandler.ProcessRequests : DataCollection started.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:07:57.192,<PHONE_NUMBER>4182, datacollector.dll, DataCollectionRequestHandler.ProcessRequests : Datacollector received message: (DataCollection.TestHostLaunched) -> {
  "ProcessId": 80
}
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.144,<PHONE_NUMBER>4818, datacollector.dll, DataCollectionRequestHandler.ProcessRequests : Datacollector received message: (DataCollection.AfterTestRunEnd) -> false
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:17:28.153,<PHONE_NUMBER>9843, datacollector.dll, [coverlet]CoverletCoverageDataCollector: SessionEnd received
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.175,<PHONE_NUMBER>7785, datacollector.dll, AssemblyResolver.OnResolve: coverlet.collector.resources: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.176,<PHONE_NUMBER>1243, datacollector.dll, AssemblyResolver.OnResolve: coverlet.collector.resources: Failed to load assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.177,<PHONE_NUMBER>5393, datacollector.dll, AssemblyResolver.OnResolve: coverlet.collector.resources: Resolving assembly.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.178,<PHONE_NUMBER>8576, datacollector.dll, AssemblyResolver.OnResolve: coverlet.collector.resources: Resolved from cache.
TpTrace Warning: 0 : 61, 1, 2020/02/20, 06:17:28.191,<PHONE_NUMBER>1693, datacollector.dll, Data collector 'datacollector://microsoft/CoverletCodeCoverage/1.0' logged the following warning: [coverlet]Coverlet.Collector.Utilities.CoverletDataCollectorException: CoverletCoverageDataCollector: Failed to get coverage result
 ---> System.IO.IOException: The process cannot access the file '/tmp/PayrollSteps.Core_5073676f-963e-4708-b743-93afbcfe1425' because it is being used by another process.
   at System.IO.FileStream.Init(FileMode mode, FileShare share, String originalPath)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at Coverlet.Core.Helpers.FileSystem.NewFileStream(String path, FileMode mode) in D:\git\coverletToRelease\src\coverlet.core\Helpers\FileSystem.cs:line 43
   at Coverlet.Core.Coverage.CalculateCoverage() in D:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 352
   at Coverlet.Core.Coverage.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 137
   at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage) in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageWrapper.cs:line 44
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 91
   --- End of inner exception stack trace ---
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 96
   at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e) in D:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverletCoverageCollector.cs:line 148
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:17:28.195,<PHONE_NUMBER>1210, datacollector.dll, [coverlet]CoverletCoverageDataCollector: Disposing
TpTrace Error: 0 : 61, 1, 2020/02/20, 06:17:28.199,<PHONE_NUMBER>8902, datacollector.dll, DataCollectionAttachmentManager.GetAttachments: Fail to get attachments: System.Collections.Generic.KeyNotFoundException: The given key 'Microsoft.VisualStudio.TestPlatform.ObjectModel.DataCollection.DataCollectionContext' was not present in the dictionary.
   at System.Collections.Generic.Dictionary`2.get_Item(TKey key)
   at Microsoft.VisualStudio.TestPlatform.Common.DataCollector.DataCollectionAttachmentManager.GetAttachments(DataCollectionContext dataCollectionContext)
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.200,<PHONE_NUMBER>5552, datacollector.dll, DataCollectionManager.CleanupPlugins: CleanupPlugins called
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:17:28.201,<PHONE_NUMBER>8493, datacollector.dll, DataCollectionManager.CleanupPlugins: Cleaning up 1 plugins
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:17:28.203,<PHONE_NUMBER>6068, datacollector.dll, dataCollectorInfo.DisposeDataCollector: calling Dispose() on Coverlet.Collector.DataCollection.CoverletCoverageCollector
TpTrace Verbose: 0 : 61, 1, 2020/02/20, 06:17:28.204,<PHONE_NUMBER>3052, datacollector.dll, [coverlet]CoverletCoverageDataCollector: Disposing
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.206,<PHONE_NUMBER>1077, datacollector.dll, DataCollectionManager.CleanupPlugins: CleanupPlugins finished
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.215,<PHONE_NUMBER>7085, datacollector.dll, DataCollectionRequestHandler.ProcessRequests : Session End message received from server. Closing the connection.
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.238,<PHONE_NUMBER>8552, datacollector.dll, Closing the connection !
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.240,<PHONE_NUMBER>5285, datacollector.dll, DataCollectionRequestHandler.ProcessRequests : DataCollection completed
TpTrace Information: 0 : 61, 1, 2020/02/20, 06:17:28.241,<PHONE_NUMBER>9810, datacollector.dll, Program.Main: exiting datacollector process.
TpTrace Information: 0 : 61, 20, 2020/02/20, 06:17:28.417,<PHONE_NUMBER>9036, datacollector.dll, DataCollector: ParentProcess '48' Exited.

Can you attach also "host" log(where inproc collector is injected)?
And also enable tracker? https://github.com/tonerdo/coverlet/blob/master/Documentation/Troubleshooting.md#enable-injected-tracker-log
To undestand if for some reason hit file is read when someone wants to persist-hit on the same.

@MarcoRossignoli I added them to this gist: https://gist.github.com/abe545/892b1183ec15b22cc5df80cc7d70652d
I didn't spot any other references to that hits file than the exceptions, but maybe I don't know what I'm actually looking for.

Okay, I updated the gist with the tracker files. Looks like the tracker is trying to unload the module 2 times, and the second time is where it is failing.

@abe545  can you try to generate same log with master version?I added process id to tracker log on master https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Instrumentation/ModuleTrackerTemplate.cs#L186
So we can be sure that there is "another" process that unloads lib and not another thread of same process.
This is the guide for nightly https://github.com/tonerdo/coverlet/blob/master/Documentation/ConsumeNightlyBuild.md
Thank's a lot for you help on debugging this issue...without a repro or a complete source is complex....you can also try to attach live to understand from where that dll is loaded, if it's shared between two process...but I don't know if works inside a container https://github.com/tonerdo/coverlet/blob/master/Documentation/Troubleshooting.md#enable-collector-instrumentation-debugging

@MarcoRossignoli I'll give it a shot. And thank you for all your help with this! I really did try to create a repro that I could share, but unfortunately was unable to isolate it. I'm sure it is something funky we're doing in some of these tests, as it doesn't happen in some filtered test runs, always happens in others, and occasionally happens in still more.

@MarcoRossignoli this is the hits file after using the nightly:
[2/20/2020 4:48:53 PM P:74 T:5]Unload called for '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Core.dll'
[2/20/2020 4:48:53 PM P:74 T:5]Flushing hit file '/tmp/PayrollSteps.Core_fbfbf202-a9ad-417b-b813-696d7a409356'
[2/20/2020 4:48:53 PM P:74 T:5]Hit file '/tmp/PayrollSteps.Core_fbfbf202-a9ad-417b-b813-696d7a409356' flushed, size 245736
[2/20/2020 4:48:53 PM P:74 T:2]Unload called for '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Core.dll'
[2/20/2020 4:48:53 PM P:74 T:2]Flushing hit file '/tmp/PayrollSteps.Core_fbfbf202-a9ad-417b-b813-696d7a409356'
[2/20/2020 4:48:53 PM P:74 T:2]Failed to create new hits file '/tmp/PayrollSteps.Core_fbfbf202-a9ad-417b-b813-696d7a409356'
System.IO.IOException: The file '/tmp/PayrollSteps.Core_fbfbf202-a9ad-417b-b813-696d7a409356' already exists.
   at Interop.ThrowExceptionForIoErrno(ErrorInfo errorInfo, String path, Boolean isDirectory, Func`2 errorRewriter)
   at Microsoft.Win32.SafeHandles.SafeFileHandle.Open(String path, OpenFlags flags, Int32 mode)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at Coverlet.Core.Instrumentation.Tracker.PayrollSteps.Core_fbfbf202-a9ad-417b-b813-696d7a409356.UnloadModule(Object , EventArgs )
[2/20/2020 4:48:53 PM P:74 T:2]Current hits found '61433'

If I understand this correctly, it is 2 different threads in the same process trying to write the file?

@abe545 yep...but that is expected...if for some reason unload is called more than one time that error is a "benign error".
Btw I've got a suspect...could be a timing issue...at the moment we subscribe to 2 event...process exit and app domain unload https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Instrumentation/ModuleTrackerTemplate.cs#L36
Domain unload is for .net framework and so it's expected error above, but is not expected on .net core.
But I think that:

out proc collector call inproc collector that run unload
out of proc collector call CalculateCoverage and access to hit file
at same time host process is killed and process exit run calling write hits, this generage error for step 2.

Can you try to dotnet pack this test branch and run coverage with generated packages? https://github.com/MarcoRossignoli/coverlet/tree/issue_736
I added sync access to hit file also during CalculateCoverage...if after unload called by outofproc collector process is killed it doesn't write on file thank's to mutex.

Okay, so the result is that that the error is still in the hits file (this makes sense), but then it bombs with:
 System.Threading.AbandonedMutexException: The wait completed due to an abandoned mutex.
   at System.Threading.WaitHandle.WaitOneNoCheck(Int32 millisecondsTimeout)
   at System.Threading.WaitHandle.WaitOne()
   at Coverlet.Core.Coverage.CalculateCoverage() in C:\code\coverlet\src\coverlet.core\Coverage.cs:line 333
   at Coverlet.Core.Coverage.GetCoverageResult() in C:\code\coverlet\src\coverlet.core\Coverage.cs:line 136
   at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage) in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageWrapper.cs:line 44
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageManager.cs:line 91         --- End of inner exception stack trace ---
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageManager.cs:line 96         at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageReports() in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageManager.cs:line 79        at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e) in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverletCoverageCollector.cs:line 148.

I'm going to mess around with coverlet locally to see if I can output better errors, now that I have it setup to use the locally packed nuget.

So seem the issue is not tracker vs getcoverage the mutex is out of finally on purpose, another test to definitely understand if it's a Coverlet issue(coverlet self lock files) is to remove the subscription to appdomain a appexit in tracker, so only collector will call unload

The other thing I saw was this in the main log file (I updated the logger to output milliseconds):
TpTrace Verbose: 0 : 44, 13, 2020/02/21, 01:14:27.708,<PHONE_NUMBER>04076, vstest.console.dll, TestRequestSender.EndSession: Sending end session.
TpTrace Warning: 0 : 44, 13, 2020/02/21, 01:14:27.809,<PHONE_NUMBER>09188, vstest.console.dll, ProxyOperationManager: Timed out waiting for test host to exit. Will terminate process.

Any idea how long it waits? Looks like 100ms?

@MarcoRossignoli so not registering the DomainUnload event handler did not change anything.
However, not registering the ProcessExit event handler solved the problem. The coverage file was written successfully, and I think it is fully populated (tbh I don't have a way to tell for sure, as I don't really know what I'm looking at).
It is unclear to me if this is a real solution, or not, as I'm sure there is a good reason to register that event handler.

@MarcoRossignoli so not registering the DomainUnload event handler did not change anything.
However, not registering the ProcessExit event handler solved the problem. The coverage file was written successfully, and I think it is fully populated (tbh I don't have a way to tell for sure, as I don't really know what I'm looking at).
It is unclear to me if this is a real solution, or not, as I'm sure there is a good reason to register that event handler.

@MarcoRossignoli so not registering the DomainUnload event handler did not change anything.

Expected...we're on .net core

However, not registering the ProcessExit event handler solved the problem.

Expected in part...file is flushed when inproc collector is called and second time when process exit(thank's to subscribe) but it's unexpected that GetCoverare fails if I'm in synch between process/threads(mutex)...my branch test should resolve that

Any idea how long it waits? Looks like 100ms?

@abe545 if you're using collector timeout it's not an issue...was an issue on msbuild/.net tool, we added collector use for THAT specific problem...and yes host process is killed after tests run after 100millisecond if it doesn't return to "parent" process.
https://github.com/tonerdo/coverlet/blob/master/Documentation/KnownIssues.md#1-vstest-stops-process-execution-earlydotnet-test read all this issue and you'll find vstest team explanation.
So if you use a collector Unload(write hits) will be surely done before process kill because workflow of vstest is

dotnet test process start 2 new process outofproccollector.exe(out of process part of coverlet) and testhost.exe(with loaded inside coverlet inproccollector), the name is invented by me to simplify
tests end and outofprocollector.exe send a message to inproccollector inside testhost.exe and "WAIT" the response...and here there is a key of collector...will wait for "inproc" collector unload/write ends.
when inproc(testhost.exe) return to outofproccollector.exe tsthost.exe MUST use max 100ms to cleanup and stop, otherwise will be brutally killed(and here the issue with msbuild version of coverlet...if write is slow we stop write in the middle o before and hit file will be null or currupted).

It is unclear to me if this is a real solution, or not, as I'm sure there is a good reason to register that event handler.

This is correct...I mean if I'm using collector and I'm on .net core process exits is "unuseful" because inproc collector flush data correctly.
BTW if I'm using collector with .net framework(unsupported at the moment but maybe we'll fix...collector is compiled for netcoreapp2.1 and not standard...I'm waiting info from vstest on that, they wrote coverlet collector we only did a review) I could have domain...so I could "append new hits" on every domain unload.
The solution should be if I'm using collectors and:

If I'm on .net core runtime and have called "Unload", unsubscribe from appdomain and appexit
If I'm on .net framework and have called "Unload" the first call should unsubscribe process exit but keep domainunload.

I don't understand why my "synch" fix fails...process exit unload should wait if GetCoverage is "using" hits file and if process will be killed won't be a problem...nobody will read that hits file when GetCoverage will release mutex....
Can you retry with my branch patch and understand which is the "real exception" thrown inside GetCoverage?

@abe545 can you retry with this new version https://github.com/MarcoRossignoli/coverlet/tree/issue_736 (fetch,pull,re-pack)?

@MarcoRossignoli so I'm still using your branch (with additional logging that I added), so I'm not sure what you'd like me to try. The mutex has not yet been released when we try to acquire it in the ModuleTrackerTemplate.UnloadModule - which is called 2x for some reason.
I'm using the collector, so the 100ms timeout is still clearly an issue in my setup, as the code in the Coverage.CalculateCoverage is taking > 100ms to re-write the file. I added log statements that occur every 100 iterations of the collector that writes the hits file, and it got through 14,800 before it stops logging, and coverlet reports this error in the main log + on the command line:
Data collector 'XPlat code coverage' message: [coverlet]Coverlet.Collector.Utilities.CoverletDataCollectorException: CoverletCoverageDataCollector: Failed to get coverage result
 ---> System.Threading.AbandonedMutexException: The wait completed due to an abandoned mutex.
   at System.Threading.WaitHandle.WaitOneNoCheck(Int32 millisecondsTimeout)
   at System.Threading.WaitHandle.WaitOne()
   at Coverlet.Core.Coverage.CalculateCoverage() in C:\code\coverlet\src\coverlet.core\Coverage.cs:line 333
   at Coverlet.Core.Coverage.GetCoverageResult() in C:\code\coverlet\src\coverlet.core\Coverage.cs:line 136
   at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage) in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageWrapper.cs:line 44
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageManager.cs:line 91         --- End of inner exception stack trace ---
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageManager.cs:line 96         at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageReports() in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverageManager.cs:line 79        at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e) in C:\code\coverlet\src\coverlet.collector\DataCollection\CoverletCoverageCollector.cs:line 148.

Sorry, ran this/wrote my comment between your two comments. I'll try with the above.

No worries, let me know

@MarcoRossignoli so the runner exited successfully, and generated the coverage. I do still see this in logs, which is suspicious to me if the in proc collector is supposed to be allowed to finish:
TpTrace Verbose: 0 : 44, 12, 2020/02/21, 07:23:46.349,<PHONE_NUMBER>29739, vstest.console.dll, TestRequestSender.EndSession: Sending end session.
TpTrace Warning: 0 : 44, 12, 2020/02/21, 07:23:46.451,<PHONE_NUMBER>95084, vstest.console.dll, ProxyOperationManager: Timed out waiting for test host to exit. Will terminate process.

Actually is a "log bug" inside vstest to me...that log is emitted always...it doesn't check if event was signaled or not
https://github.com/microsoft/vstest/blob/462d3674c29310be0efa8f5db04d5fe058ac0858/src/Microsoft.TestPlatform.CrossPlatEngine/Client/ProxyOperationManager.cs#L201-L233
cc: @nohwnd

@abe545 can you attach tracker logs?

@abe545 can you attach tracker logs?

@MarcoRossignoli here you go: https://gist.github.com/abe545/1056bb31a23b550d9d545544f3716639

I mean set COVERLET_ENABLETRACKERLOG=1

I mean set COVERLET_ENABLETRACKERLOG=1 and attach file

These logs were generated with that environment variable set to that value. Is there a specific file you're looking for?
This is the relevant part of my docker-compose.yml I used to run the tests, and get the logs out:
  test-paychecks:
    build:
      context: .
    entrypoint: /bin/bash -c
    command: [
        "dotnet test /app/test/PayrollSteps.Api.Test/PayrollSteps.Api.Test.csproj --configuration Release --no-build -v n --collect:\"XPlat Code Coverage\" --settings /app/test/coverlet.runsettings -r /coverage/paychecks --filter \"Feature=paychecks\" --diag:log-paychecks.txt ; cp /app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/*.txt /app/trackerhits"
        ]
    environment:
      COVERLET_ENABLETRACKERLOG: "1"
    volumes:
      - ./coverage/paychecks:/coverage/paychecks
      - ./coverletlogs:/app/coverletlogs/
      - ./coverletlogs/trackerhits:/app/trackerhits

A note about the dockerfile - we build it in release mode in a previous stage, so we can use --no-build --verbosity Normal (-v n above) so we get more information about the test run.

Re-reading the documentation for that env var, I'm guessing you're looking for a file in the TrackerHitsLog folder. I'll try to get it out of the container.

I'd like to see the log message for tracker to be sure you're using patched version...should see this log https://github.com/tonerdo/coverlet/compare/master...MarcoRossignoli:issue_736#diff-164040e68c2b496a18449c2363998152R112

Ah, @MarcoRossignoli that was in the gist:
[2020-02-21T07:23:46.2623509Z P:80 T:4]Unload called for '/app/test/PayrollSteps.Api.Test/bin/Release/netcoreapp3.1/PayrollSteps.Core.dll' FlushType: InProcessCollectorFlush
[2020-02-21T07:23:46.2626545Z P:80 T:4]Flushing hit file '/tmp/PayrollSteps.Core_5da02297-149d-458b-a477-3a6dd6bf832e'
[2020-02-21T07:23:46.2627689Z P:80 T:4]Writing 61433 new hits
[2020-02-21T07:23:46.2924479Z P:80 T:4]Hit file '/tmp/PayrollSteps.Core_5da02297-149d-458b-a477-3a6dd6bf832e' flushed, size 245736

Since I built this locally from your branch, I did update the logger to output the time in a more verbose manner:
File.AppendAllText(Path.Combine(Path.GetDirectoryName(location), Path.GetFileName(location) + "_tracker.txt"), $"[{DateTime.UtcNow.ToString("o")} P:{Process.GetCurrentProcess().Id} T:{Thread.CurrentThread.ManagedThreadId}]{logText}{Environment.NewLine}");

Ah, @MarcoRossignoli that was in the gist

Ah ok missed that so it seems to work...do you see error or the fix seem a good idea?

I don't see any errors anymore. As far as I can tell, this fixes the issues I'm having. Thanks again for your help!
If you still would like a repro, I think I could do it by generating a very large file (on the order of 20K lines) of meaningless code that is executed under a test... That should result in the same behavior of the file being written 2x, and the second taking > 100ms

If you can generate a repro could be great...I need to understand all the implication of my patches because tracker is a "sensible" component.
For now use my branch patch if you can and I'll do more investigation checks(busy weeks at the moment so I won't merge to master soon).
But I think this is definely a bug.

@MarcoRossignoli I've been able to partially reproduce this issue in a dummy repo - ultimately coverlet succeeds in this project, so I'm not sure if it is useful. It produces the following behavior:

The hits file is a similar size to my real project
The tracker log has the same error that I see with the nightly build in my real project
The detailed tracker hits log is only generated once per run (indicating to me it is dying in the same area of code as my real project)
If I use the mutex based first attempt to fix my issue, this dies with the same mutex abandoned exception.

Like I said, I'm not sure how useful this is since coverlet finishes successfully, but let me know if you'd like me to share it.

Put here the link and feel free to stop to invest time you did a lot of test and I don't want to "take" your time more than this...we understood the issue, now I need only to understand if remove process exit for collector is a good idea or not...because today we have again a lot of user that upgrades to for instance collector 1.2.0 but doesn't upgrade test sdk...with the fix this lead to "no hit files generated"(https://github.com/tonerdo/coverlet/blob/master/Documentation/KnownIssues.md#2-upgrade-coverletcollector-to-version--100).
I need to understand if it's good or not(with process exits we have always a generated file, even if it's not "expected").

I really appreciate your help @MarcoRossignoli! Here is the repository: https://github.com/namely/CoverletErrorRepro

Thanks!

@MarcoRossignoli I was just thinking about this - what if the file wasn't generated if it already exists?  Right now, if the file doesn't exist, it will be rewritten one line at a time, and this seems particularly slow. I'm not entirely sure if I'm correct with this assumption, but it seems like that is just re-writing the data that already exists in the file... If it doesn't open the hits file to rewrite it, I'm pretty sure it would fix my issue. In fact, I'm going to try that tomorrow morning, and I'll get back to you if it works.

I'm not entirely sure if I'm correct with this assumption

At the moment file is created if doesn't exists under a mutex https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Instrumentation/ModuleTrackerTemplate.cs#L86
But if file exists the new hit is "added" to existing files. This is needed because we could have more than one app domain(on .net framework) so we need to keep this behaviour(if I understood well what you mean).

I'm not entirely sure if I'm correct with this assumption

At the moment file is created if doesn't exists under a mutex https://github.com/tonerdo/coverlet/blob/master/src/coverlet.core/Instrumentation/ModuleTrackerTemplate.cs#L86
But if file exists the new hit is "added" to existing files. This is needed because we could have more than one app domain(on .net framework) so we need to keep this behaviour(if I understood well what you mean).

If it is only needed for the full framework, we could skip it for .net core? And sorry, I didn't have time to test it yesterday, but will hopefully get a chance today.

If it is only needed for the full framework, we could skip it for .net core? And sorry, I didn't have time to test it yesterday, but will hopefully get a chance today.

We should/could...and this is a concern to me...until today we did't differentiate two run...indeed my path does that if you take a look.

@MarcoRossignoli I'm seeing the same issue on dotnet/runtime:
coverlet.collectors: 1.2.1
Microsoft.NET.Test.Sdk: 16.7.0-preview-20200429-01
C:\git\runtime4\src\libraries\System.Text.RegularExpressions\tests>dotnet test -f netcoreapp5.0 /p:Coverage=true
Microsoft (R) Build Engine version 16.7.0-preview-20251-04+8e4c57314 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  TestUtilities -> C:\git\runtime4\artifacts\bin\TestUtilities\netcoreapp5.0-Debug\TestUtilities.dll
  System.Text.RegularExpressions.Tests -> C:\git\runtime4\artifacts\bin\System.Text.RegularExpressions.Tests\netcoreapp5.0-Debug\System.Text.RegularExpressions.Tests.dll
Test run for C:\git\runtime4\artifacts\bin\System.Text.RegularExpressions.Tests\netcoreapp5.0-Debug\System.Text.RegularExpressions.Tests.dll(.NETCoreApp,Version=v5.0)
Starting test execution, please wait...

A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:01.27] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexConstructorTests.Ctor'; falling back to single test case.
[xUnit.net 00:00:01.41] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexMatchTests.Match_Advanced'; falling back to single test case.
[xUnit.net 00:00:01.42] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexMultipleMatchTests.Matches'; falling back to single test case.
[xUnit.net 00:00:01.44] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexReplaceTests.Replace_MatchEvaluator_Test'; falling back to single test case.
[xUnit.net 00:00:01.64] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexCompilationInfoTests.Ctor_ValidArguments_CheckProperties'; falling back to single test case.
[xUnit.net 00:00:01.64] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexCompilationInfoTests.MatchTimeout_GetSet_Throws'; falling back to single test case.
[xUnit.net 00:00:01.64] System.Text.RegularExpressions.Tests: Non-serializable data ('System.Object[]') found for 'System.Text.RegularExpressions.Tests.RegexCompilationInfoTests.MatchTimeout_GetSet_Success'; falling back to single test case.
[xUnit.net 00:00:16.24] System.Text.RegularExpressions.Tests: Skipping test case with duplicate ID 'b980efc2e49199eb1830a54425d556e93546291a' ('System.Text.RegularExpressions.Tests.RegexGroupTests.Groups(cultureName: null, pattern: "(cat)(\\c[*)(dog)", input: "asdlkcat\x1bdogiwod", options: None, expectedGroups: ["cat\x1bdog", "cat", "\x1b", "dog"])' and 'System.Text.RegularExpressions.Tests.RegexGroupTests.Groups(cultureName: null, pattern: "(cat)(\\c[*)(dog)", input: "asdlkcat\x1bdogiwod", options: None, expectedGroups: ["cat\x1bdog", "cat", "\x1b", "dog"])')
Data collector 'XPlat code coverage' message: [coverlet]Coverlet.Collector.Utilities.CoverletDataCollectorException: CoverletCoverageDataCollector: Failed to get coverage result
 ---> System.IO.IOException: The process cannot access the file 'C:\Users\vihofer\AppData\Local\Temp\System.Text.RegularExpressions_31d2b5e9-3002-4998-bb30-3bd531e6090c' because it is being used by another process.
   at System.IO.FileStream.ValidateFileHandle(SafeFileHandle fileHandle)
   at System.IO.FileStream.CreateFileOpenHandle(FileMode mode, FileShare share, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)
   at System.IO.FileStream..ctor(String path, FileMode mode)
   at Coverlet.Core.Helpers.FileSystem.NewFileStream(String path, FileMode mode) in c:\git\coverletToRelease\src\coverlet.core\Helpers\FileSystem.cs:line 43
   at Coverlet.Core.Coverage.CalculateCoverage() in c:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 352
   at Coverlet.Core.Coverage.GetCoverageResult() in c:\git\coverletToRelease\src\coverlet.core\Coverage.cs:line 135
   at Coverlet.Collector.DataCollection.CoverageWrapper.GetCoverageResult(Coverage coverage) in c:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageWrapper.cs:line 44
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in c:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 91
   --- End of inner exception stack trace ---
   at Coverlet.Collector.DataCollection.CoverageManager.GetCoverageResult() in c:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverageManager.cs:line 96
   at Coverlet.Collector.DataCollection.CoverletCoverageCollector.OnSessionEnd(Object sender, SessionEndEventArgs e) in c:\git\coverletToRelease\src\coverlet.collector\DataCollection\CoverletCoverageCollector.cs:line 153.
Results File: C:\git\runtime4\artifacts\bin\System.Text.RegularExpressions.Tests\netcoreapp5.0-Debug\TestResults\vihofer_DESKTOP-803H9R0_2020-05-05_11_24_34.trx
Html test results file : C:\git\runtime4\artifacts\bin\System.Text.RegularExpressions.Tests\netcoreapp5.0-Debug\TestResults\TestResult_vihofer_DESKTOP-803H9R0_20200505_112454.html

cc @nohwnd in case this is data collector VSTest related.

Not I know where is the problem, happeny very few time, there is a race related to process exit of test host and get coverage result of out of proc collector

Where would be the right place to fix the race? In VSTest or here in coverlet?

Coverlet for what I understood

@abe545 are running your branch fix in your projects?

I've a non too invasive fix in mind, I'll try asap.
TL; DR;
When collectors was created we didn't take into account the ProcessExit callback. So sometime happens that in proc collector flush and meanwhile out of proc one try to load hits file and process exits of host process re-flush the file and so race.
We need to add a flag to tracker like flush and when in proc collector flush set this flag to false, this flag will be evaluated during process exists, or something like that.

Just to let you guys know, I have had similar problems (under windows) and traced them back to McAfee Endpoint Security 10.7. After uninstalling McAfee, everything went well. Also a downgrade to McAfee 10.6 should do the trick, will let you know when I can confirm that.

That could be another reason thanks.


Crashes due to increased stack size requirements

Required information
Operating system:
Windows 10 & Windows 11
Compiler version:
msvc: 19.31.31104.0
Observed result or behaviour:
When starting the example with
.\build\iceoryx_examples\singleprocess\Debug\single_process.exe

it immediately crashes
Expected result or behaviour:
A running example where the received and send numbers are shown
Conditions where it occurred / Performed steps:
.\build\iceoryx_examples\singleprocess\Debug\single_process.exe

The reason of the crash is that the stack size of roudi is increased since the service registry resides now on the stack. The CMAKE_CXX_STACK_SIZE would be a temporary solution (temporary since cmake does not support it officially).
A better solution would be to set the stack size uniformly to 8Mb for every application which can be done during link time, see: https://stackoverflow.com/questions/2275550/change-stack-size-for-a-c-application-in-linux-during-compilation-with-gnu-com

The cmake flag -DCMAKE_CXX_STACK_SIZE=8000000 fixes the issue.

FYI @dkroenke

@elBoberido stated that we should not increase the stack size for every target. But it would make sense to decrease the stack size to the QNX default on or ubuntu gcc 5.4 target. This should work with CMAKE_CXX_STACK_SIZE.

The problem is that linux can use 8MB or more for stack since it is over committing on memory, i.e. it is virtual memory until it is actually used. Other OSes don't do that. So if we set the stack size to 8MB each app will consume 8MB of physical memory for the main thread + (depending of how this option works) 8MB for each additional thread. This makes iceoryx apps extremely memory hungry on non linux platforms


Support Incremental Builds by not re-publish a container if nothing's changed

If you run dotnet publish /t:PublishContainer on a project that hasn't changed since the last container publish, the SDK will build a new image, even though nothing's changed
Repro Steps

Run dotnet publish /t:PublishContainer
Run dotnet publish /t:PublishContainer a second time, without making any other code changes

Expected Results
The second (and subsequent) publish command shouldn't build a whole new container until something else has changed
Actual Results
The second (and subsequent) commands build a new image - note how in the below example the image id has changed between the two publishes.
$> dotnet publish app /t:PublishContainer

  Determining projects to restore...
  All projects are up-to-date for restore.
  Sample -> C:\src\ACTest\artifacts\bin\Sample\Sample.dll
  Sample -> C:\src\ACTest\artifacts\publish\Sample\
  Building image 'actest/myapp' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/aspnet:8.0'.
  Pushed image 'actest/myapp:latest' to local registry via 'docker'.

$> docker images actest/myapp
REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
actest/myapp   latest    7bef4d40e5d3   4 seconds ago   221MB

$> dotnet publish app /t:PublishContainer

  Determining projects to restore...
  All projects are up-to-date for restore.
  Sample -> C:\src\ACTest\artifacts\bin\Sample\Sample.dll
  Sample -> C:\src\ACTest\artifacts\publish\Sample\
  Building image 'actest/myapp' with tags 'latest' on top of base image 'mcr.microsoft.com/dotnet/aspnet:8.0'.
  Pushed image 'actest/myapp:latest' to local registry via 'docker'.

$> docker images actest/myapp
REPOSITORY     TAG       IMAGE ID       CREATED         SIZE
actest/myapp   latest    7c293a165f4d   5 seconds ago   221MB

Excellent report, thanks for writing it.
There are two main sources of incrementality failures that I see today that would need to be addressed:

The Task works directly on the $(PublishDir), but for incrementality tracking purposes we should be depending on the specific files inside this directory (so in MSBuild terms an Item with an Include of $(PublishDir)/**/*.*
The other major inputs need to be captured in a file that could be written to the intermediate output directory for incrementality purposes:

Base image SHA
ENV directives
Labels/annotations
USER
WORKDIR
CMD/ENTRYPOINT

Incremental checks on Labels would need to ignore the ContainerGenerateLabelsImageCreated labels that get defaulted to the current time.  Or perhaps there we can use another more stable date that can be used (e.g. the LastModifiedDate of the entry point file)


fail install chromium on RetroPie 4.3

On fresh 4.3 install
$ sudo su -
# grep __version /home/pi/RetroPie-Setup/retropie_packages.sh
__version="4.3"
# git clone https://github.com/zerojay/RetroPie-Extra.git
# cd RetroPie-Extra/
# ./install-extras.sh
# cd /home/pi/RetroPie-Setup
# ./retropie_packages.sh chromium
# reboot

I gets :
boost::filesystem::filesystem_error
boost::filesystem::status: Permission denied: /root/RetroPie/roms/ports

Shouldn't be happening as it shouldn't be attempting to run it as root. Did you set up X so that anyone could run it yet, as shown on the main page of the repo?

Not the first time I've seen someone report it though.

What happens if you run the installation of chromium through RetroPie-Setup as selected from emulationstation?

Installation works 100% from the setup script.

Installation should only be done through the setup script. Installing from directly running ./retropie_packages isn't something guaranteed as it's likely the RetroPie-Setup script does something like drops permissions back to the pi user before running it or something along these lines. @erwanJarno, can you please delete the package's installation and run it through RetroPie-Setup as intended and see if you get the same issues?

The only thing is that the latest chrome is version 62 and the script installs version 56 can this be corrected?
Thanks

As far as I'm aware, it's installing whatever the latest version of the package is in Raspbian.

So only raspbian stretch can have the latest version as i see.
thanks

my full proc :

### main computer
sudo su -
df -h
diskutil list
diskutil unmountDisk /dev/disk4
set +o posix
dd bs=4m if=<(gunzip < /Users/me/Downloads/retropie-4.3-rpi1_zero.img.gz) of=/dev/rdisk4;sync
diskutil unmountDisk /dev/disk4

### Raspberry
passwd
sudo systemctl enable ssh
sudo systemctl start ssh

### main computer
ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no<EMAIL_ADDRESS>sudo su -
#git -C /home/pi/RetroPie-Setup/ show
grep __version /home/pi/RetroPie-Setup/retropie_packages.sh
HOSTNAME="mypi"
printf "${HOSTNAME}" > /etc/hostname
sed -r -i 's/^(<IP_ADDRESS>[ \t]*).*$/\1'"${HOSTNAME}"'/' /etc/hosts
/etc/init.d/hostname.sh
CONFIG_FILE="/boot/config.txt"
KEY='hdmi_force_hotplug';VALUE='1';sed -r -i 's/^#?('"${KEY}"' *= *).*$/\1'"${VALUE}"'/' "${CONFIG_FILE}"
KEY='hdmi_drive';VALUE='2';sed -r -i 's/^#?('"${KEY}"' *= *).*$/\1'"${VALUE}"'/' "${CONFIG_FILE}"
exit
export http_proxy=http://$PROXY_USERNAME:$PROXY_PASSWORD@$PROXY_SERVER:$PROXY_PORT
#https://github.com/zerojay/RetroPie-Extra
git clone https://github.com/zerojay/RetroPie-Extra.git
cd RetroPie-Extra/
./install-extras.sh
sudo su -
export http_proxy=http://$PROXY_USERNAME:$PROXY_PASSWORD@$PROXY_SERVER:$PROXY_PORT
cd /home/pi/RetroPie-Setup
./retropie_setup.sh #(accept root add to input and video groups) Manage Packages -> Manage experimental packages -> 310/chromium
dpkg-reconfigure xserver-xorg-common
reboot

Output :
# dpkg-reconfigure xserver-xorg-common
dpkg-query: package 'xserver-xorg-common' is not installed and no information is available
Use dpkg --info (= dpkg-deb --info) to examine archive files,
and dpkg --contents (= dpkg-deb --contents) to list their contents.
/usr/sbin/dpkg-reconfigure: xserver-xorg-common is not installed

# reboot
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
 what(): boost::filesystem::status: Permission denied: "/root/RetroPie/roms/ports"
Aborted

why going to all this trouble while you can install it from the setup-script so easy.

in this version I have use setup-script :
./retropie_setup.sh #(accept root add to input and video groups) Manage Packages -> Manage experimental packages -> 310/chromium

setup script need to run with sudo

#(accept root add to input and video groups) <--- There is no request to add root to any groups as part of retropie_setup.sh and I suspect that this is your problem. You're somehow running things as root when they should not be which is why you are getting "/root/RetroPie/roms/ports" permissions errors.

Also, I've corrected the command to ask for permission for other users to run X (which I could swear I had done before but...)
The Chromium installation script should properly install the app you need and the readme is now updated to give you the proper command to run. Give it another shot and let me know.

insted of using :
export http_proxy=http://${PROXY_USERNAME}:${PROXY_PASSWORD}@${PROXY_SERVER}:${PROXY_PORT}
I have use :
echo 'Acquire::http::Proxy "http://'/${PROXY_USERNAME}:${PROXY_PASSWORD}@${PROXY_SERVER}:${PROXY_PORT}'";' > /etc/apt/apt.conf.d/10proxy
And lauched retropie setup from GUI
It worked

why dont you just try to reset the permissions from the script.

Okay, so we can close this as fixed then?

yesn, thanks you for help


[SPARK-11379][SQL] ExpressionEncoder can't handle top level primitive type correctly

For inner primitive type(e.g. inside Product), we use schemaFor to get the catalyst type for it, https://github.com/apache/spark/blob/master/sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/ScalaReflection.scala#L403.
However, for top level primitive type, we use dataTypeFor, which is wrong.

cc @marmbrus

Merged build triggered.

Merged build started.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44535/
Test FAILed.

Merged build finished. Test FAILed.

retest this please.

Merged build triggered.

Merged build started.

Test build #44553 has started for PR 9337 at commit 8b98d03.

Test build #44553 has finished for PR 9337 at commit 8b98d03.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/44553/
Test PASSed.

Thanks, merging to master.


Improve grammar

This colloquial abbreviation is folksy and should not appear in serious writing. Additionally, without the word "are" before "gonna" the grammar is also incorrect.

Hi @PaluMacil, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!

This seems like a small (but important) contribution, so no Contribution License Agreement is required at this point. Real humans will now evaluate your PR.

TTYL, DNFBOT;

thanks


TS-17 Add SuperKey alias support

FileName_Info added a list of alias names for the super keys.
Filename modified to use alias names, a list of keys being built, and names by enumeration value.
Types added file name enumeration values.
Build Slice Action supports list of external co-managed files.
Layouts defined co-managed file information.
Signed-off-by: johnholt<EMAIL_ADDRESS>

@johnholt Who can review this?

Tony reviewed with no issues.  @ghalliday  should take a look at how I use NOTHOR(APPLY(... to see if this code is setting a good example or if the File Services actions should be re-worked.

@richardkchapman  @ghalliday  This is good to go.  It is a simple initial version that supports a full replacement of the collection for each build.  A more complicated incremental update or even a slice scheme can be added later if desired.

@johnholt I think the file services calls are ok.  You might need to force the input dataset to a workunit global temporary though, otherwise if mfn is something more than an inline dataset the code will fail to generate.  E.g.
EXPORT Manage_Superkeys(FileName_Info info, DATASET(Managed_File_Names) mfn) := FUNCTION
globalmfn := global(mfn, few);
ac := SEQUENTIAL(
// Make sure the aliases exist, create as necessary
NOTHOR(APPLY(globalmfn,


Document officially supported font formats?

I would like to use woff or woff2 fonts as they're a smaller format compared to ttf. However, I'm not sure if they're officially supported. woff fonts appear to work on my local Mac, but not sure if it's safe to use on all platforms (Windows, Linux)?
Could you please add a list of supported font formats on the Fonts page? https://flutter.io/custom-fonts/
Thanks!

@Hixie Sorry to ping directly -- Do you know of anyone who has info on this? Would like to include this information in the Flutter Cookbook!

We rely on Skia to provide font managers, which in turn delegate to various third-party font libraries or platform font APIs.  For example, on Android Skia is using FreeType, and Flutter is currently embedding version 2.6 of FreeType.
https://www.freetype.org/index.html#news mentions that support for WOFF fonts was added prior to version 2.6, but I don't know if anyone has tried using it in Flutter.

We should probably make sure we disable WOFF if we're shipping the decoder in our binary (the decoder is like 100k of data IIRC). If we're not, but still support it (e.g. because the platform supports it), then that's fine, and we should recommend that people use it.

The above PR fully fixes this issue.


Don't confirm git gud solution if level has ever been completed

Once #32 and #187 are done, we should allow users to run git gud solution without needing to confirm if they have already completed the level at any point. Code would go in  Level.has_ever_been_completed()

@sahansk2 This one is going to you because you're implementing all the related stuff. Can you comment here so I can assign it to you?

@benthayer Scoop


Will it have any impact if I remove the Microsoft.Data.SqlClient reference?

Hi, if I delete the Microsoft.Data.SqlClient reference and remove the related code and only use it in SQL Server, will it have any impact?

saxdasf,
I am trying to understand you would want to remove that reference. The framework only support SQL Server at this time.


try to refresh topology of nodes before totally give up

In some case the cluster is not dead but one of the nodes come with new IPs.
We should try to refresh the topology and run the query again

@wnykuang Can you give a scenario or case where this really happens a lot? For example does this happen a lot when you are using a redis cluster in a cloud envrionment or something similar? Also i think that setting it to trying a random node and refreshing the table asap conflicts with eachother as it would basically reset and make your client lookup the entire cluster again at every time a node drops off and that is usually not something that is wanted by default.

@wnykuang Can you give a scenario or case where this really happens a lot? For example does this happen a lot when you are using a redis cluster in a cloud envrionment or something similar? Also i think that setting it to trying a random node and refreshing the table asap conflicts with eachother as it would basically reset and make your client lookup the entire cluster again at every time a node drops off and that is usually not something that is wanted by default.

When we deployed the redis-cluster in kubernetes, sometimes k8s killed one of the redis pods for some reason and will recover in seconds. In that scenario node's IP address be changed and I don't think it will be recovered from try_random_node since the err is on https://github.com/Grokzen/redis-py-cluster/blob/master/rediscluster/client.py#L378 line.
If I have misunderstood any thing, please let me know. Thanks

@wnykuang Can you give a scenario or case where this really happens a lot? For example does this happen a lot when you are using a redis cluster in a cloud envrionment or something similar? Also i think that setting it to trying a random node and refreshing the table asap conflicts with eachother as it would basically reset and make your client lookup the entire cluster again at every time a node drops off and that is usually not something that is wanted by default.

Yeah, I agree with the self.try_random_node and self.refresh_nodes_asap is conflicted to each other.
However, sometimes the IP address of node is changed and the client should refresh the topology. I don't think the decorator will be called many times tough, but I think it should be fine( to refresh the nodes IP when it broken), right?

@wnykuang I can't really merge this as is. What i want you to do for this to be mergable is to first squash all of your changes into a single commit. Secondly you need to move the code over to client.py now as the method you tried to fix has been moved into client.py into the method execute_command. You also need to fix or figure out why tests fail when i tried to add this code it started to fail the tests, more specifically test_busy_loading_disconnects_socket that fails for some unknown reason. Until this is done, i won't merge this into the codebase.


Fix unable to edit only country code bug

This is a good fix. I'll use this method to fix similar bugs in the future.


Multiple Thermostats

Appologies if I'm being obtuse, how do you specify multiple thermostats in the config file?

The connector doesn't directly support multiple thermostats. I've updated the FAQ with a recommended workaround: https://github.com/cdzombak/ecobee_influx_connector/blob/main/README.md#does-the-connector-support-multiple-thermostats


Quality of life improvements

TODO

[x] Add a .clear() function property to memoized functions to allow for cache clearing
[x] Improving types of the memoized function
[x] Adding a node script to compare the performance of memoize-one against other memoization libraries
[x] Upgrade all dependencies
[x] Shift over from TravisCI to Github actions
[x] Add type tests to ensure types are working as expected
[ ] update flow types
[ ] Release notes
[ ] Update README to include new performance command + .clear()

To be decided

[ ] Should this version be a minor or a major
[ ] Do we need type:module in the package.json?
[ ] Do we add .length? https://github.com/alexreardon/memoize-one/pull/18
[x] Should we update the memoized functions .name and/or .displayName property? (see #122) No.

Adding a .name / .displayName property to a memoized function does not yield as good of results as I would have liked, and to support ie11 the .name property assignment would need to be wrapped in a try/catch; potentially further hurting performance.

Do we add .length?

Yes. Some libraries, like redux.connect use this information.

Adding a .name / .displayName property

Can it be dev-mode only? As it does not make any sense to pass minified, uglified and tersed named anywhere.

I'm exploring dev tooling separately (there is a lot more that could be done) so for now i'll stay away from adding name

Can we do the .length assignment in ie11?

Need to check if this working in ie11:
// Faking the 'length' property of the function to match the original function
  Object.defineProperty(memoized, 'length', {
    writable: false,
    configurable: true,
    value: resultFn.length,
  });

Now to get an ie11 environment! I haven't needed one in a while 😅

It would be good also to confirm if setting .length like this causes any deoptimisations

Adding .length seems to have a non-trivial performance hit

I'm currently leaning towards not adding .length as it seems to have a non-trivial performance impact

It turns out adding .length doesn't have the original performance drawback I was seeing. I was not setting the property value which I think was having a negative impact

Based on these numbers I am happy to start looking at ie11 support

Code to add the .length property:
Object.defineProperty(memoized, 'length', {
	  writable: false,
	  enumerable: false,
	  configurable: true,
	  value: resultFn.length,
});

This will throw on ie11. I could wrap the assignment in a try/catch. Right now this project still supports ie11, and this project is still leaned on super heavily in the JS community. I'm not looking to drop ie11 support just yet.
I am currently thinking not to try to add .length (even in a try/catch). I don't want the memoized function to be different in different environments as this might cause some unexpected behaviours

Take a look at https://github.com/blakeembrey/arity/blob/master/arity.js, which I am using for a few years and it can be a good fallback for IE11
Why failback - "eval" might not be strict CSP rules compatible and is not proven to work in all environments.

So here is where the rubber hits the road; should this change be a major or a minor?
memoized function type is now more accurate
Old: result of the memoized function was being cast to ResultFn (the same type as the function that is passed in)
declare function memoizeOne<ResultFn extends (this: any, ...newArgs: any[]) => ReturnType<ResultFn>>
  (resultFn: ResultFn, isEqual?: EqualityFn): ResultFn;

New: result of memoized function is more nuanced

the returned memoized function is (this: ThisParameterType<TFunc>, ...args: Parameters<TFunc>): ReturnType<TFunc> (being clear that this is not the exact same thing as TFunc (resultFn) as we are not preserving any properties on the function (eg originalFn.foobar
return function also has a .clear() property [new API]

declare type MemoizedFn<TFunc extends (this: any, ...args: any[]) => any> = {
    clear: () => void;
    (this: ThisParameterType<TFunc>, ...args: Parameters<TFunc>): ReturnType<TFunc>;
};
declare function memoizeOne<TFunc extends (this: any, ...newArgs: any[]) => any>
  (resultFn: TFunc, isEqual?: EqualityFn<TFunc>): MemoizedFn<TFunc>;

EqualityFn type is now parametrised
Old: new and last arguments are an array of any
type EqualityFn = (newArgs: any[], lastArgs: any[]) => boolean;

New: new and last arguments are typed as the parameters to the function memoize memoized 🤩
type EqualityFn<TFunc extends (...args: any[]) => any> = (
  newArgs: Parameters<TFunc>,
  lastArgs: Parameters<TFunc>,
) => boolean;

Take a look at https://github.com/blakeembrey/arity/blob/master/arity.js, which I am using for a few years and it can be a good fallback for IE11
Why failback - "eval" might not be strict CSP rules compatible and is not proven to work in all environments.

This is very creative @theKashey! I think for now it is still best to stay away from this creativity.

memoize-one has never supported maintaining .length
I hope to drop ie11 support soonish, and so this level of creativity would not be needed to add .length (could just use Object.defineProperty)

memoize-one has never supported maintaining .length

In this case I reckon it will be nice to define this property in dev mode, and emit a warning on access. Some functionality might use .length for some purpose, and it will be close to impossible to understand why something is not working after being memoized.

@TrySound what do you think we should do with the existing flowtype? (I want to add a .clear() property to the ResultFn type)

Thanks @TrySound! I'm trying to figure out how to give the callable property the same signature as ResultFn. I worked it out for typescript, but no success with flow yet.
I suspect $Call will be needed but I haven't figured it out yet
https://flow.org/en/docs/types/utilities/#toc-call

You can try this out now with<EMAIL_ADDRESS>

[Draft] Release notes
At a glance
🧹 New .clear() function to remove the current memoization cache
🏋♀ Stronger types
🥰 Improved documentation
This release is a major, but there are no behaviour or API changes. The major is to reflect that some of the TypeScript types have been tightened which might cause some consumers TypeScript builds to break.

PSA: memoize-one will soon be dropping ie11 support
More details

New: Cache releasing with .clear() 🧹
A .clear() property is now added to memoized functions to allow you to clear its memoization cache
This is helpful if you want to:

Clear memory
Cause the underlying function to be called again without having to change arguments

import memoizeOne from 'memoize-one';

function add(a: number, b: number): number {
  return a + b;
}

const memoizedAdd = memoizeOne(add);

// first call - not memoized
const first = memoizedAdd(1, 2);

// second call - cache hit (underlying function not called)
const second = memoizedAdd(1, 2);

// 👋 clearing memoization cache
memoizedAdd.clear();

// third call - not memoized (cache was cleared)
const third = memoizedAdd(1, 2);

Improved: memoized function type

There are no API changes to memoize-one, this is merely a typing improvement

Our previous type for a memoized function was simple:
Previous
export declare type EqualityFn = (newArgs: any[], lastArgs: any[]) => boolean;

declare function memoizeOne<ResultFn extends (this: any, ...newArgs: any[]) => ReturnType<ResultFn>>(resultFn: ResultFn, isEqual?: EqualityFn): ResultFn;

A memoized function claimed to be the same type (ResultFn) as the original function. This was not true, as memoize-one does not copy of any existing object properties on the original function (TFunc)
Updated
export declare type MemoizedFn<TFunc extends (this: any, ...args: any[]) => any> = {
  clear: () => void;
  (this: ThisParameterType<TFunc>, ...args: Parameters<TFunc>): ReturnType<TFunc>;
};

declare function memoizeOne<TFunc extends (this: any, ...newArgs: any[]) => any>(
  resultFn: TFunc,
  isEqual?: EqualityFn<TFunc>,
): MemoizedFn<TFunc>;

A memoized function returns the same callable signature as the original function (TFunc → was ResultFn), but it makes it clear that no function object properties on the original function (TFunc) are being carried forward. The memoized function also now includes a .clear() function object property

This type change has been labelled as a patch (fix) as the previous type was not correct. However, you could consider it a major given that the new type is a bit narrower than before

Improved: equality function type

There are no API changes to equality functions, this is merely a typing improvement

Previous
export type EqualityFn = (newArgs: any[], lastArgs: any[]) => boolean;

Current
export type EqualityFn<TFunc extends (...args: any[]) => any> = (
  newArgs: Parameters<TFunc>,
  lastArgs: Parameters<TFunc>,
) => boolean;

This looks a little scary, but it is pretty neat! It means that you can dramatically improve the type safety of your custom equality functions if you want to.
If you are not using a custom equality function
No changes for you!
If you are using a custom equality function
Most people will not be impacted!
This type tightening allows you to be a lot stricter with the shape of your functions passed in as equality functions. If you are using generic equality functions such as lodash.isequal their types are loose and there is nothing you will need to do. But if you want to write more efficient and typesafe equality functions, you are in for a treat.
An example of what things looked like in 5.x
import memoize, { EqualityFn } from "memoize-one";

type Person = {
  id: string;
  name: string;
};

function invite(person: Person) {
  // This could do something fancy, but just keeping things basic
  console.log("invited:", person.name);
}

// Yuck, we don't know anything about the args
// Note: don't really need the `EqualityFn` type as it is just:
// `type EqualityFn = (newArgs: any[], lastArgs: any[]) => boolean;`
const isEqual: EqualityFn = (newArgs: any[], lastArgs: any[]): boolean => {
  // Yuck #2: we have to cast here
  // We would also be creating a bug if isEqual is used on a function
  // that has no arguments
  const first = newArgs[0] as Person;
  const second = lastArgs[0] as Person;
  return first.id === second.id;
};

const memoized = memoize(invite, isEqual);

const alex: Person = {
  name: "Alex",
  id: "11111"
};

memoized(alex);
// Won't do anything as `alex` has the same id as the last `alex`
memoized(alex);

The same example in 6.x
import memoize, { EqualityFn } from "memoize-one";

type Person = {
  id: string;
  name: string;
};

function invite(person: Person) {
  console.log("invited:", person.name);
}

// Yum: we know that newArgs + lastArgs are the tuple `[Person]`
const isEqual: EqualityFn<typeof invite> = ([first], [second]): boolean => {
  return first.id === second.id;
};

const memoized = memoize(invite, isEqual);

const alex: Person = {
  name: "Alex",
  id: "11111"
};

memoized(alex);
// Won't do anything as `alex` has the same id as the last `alex`
memoized(alex);

// When declared inline, our isEqual function has the correct types inferred
const inferred = memoize(invite, function isEqual([first], [second]): boolean {
  return first.id === second.id;
});

There are a few cases where this could cause your TypeScript types to start failing, so this change has been listed as a major

Improved: documentation

Cleanup and audit of examples
Added documentation for .clear()
Added documentation about function properties and the .length property
Updated performance benchmarks

Code health

Now on<EMAIL_ADDRESS>Moved from TravisCI to Github workflows
Upgraded devDependencies

The current plan is to release 6.x tomorrow 😲


FileNotFoundError: [Errno 2] No such file or directory: 'weights/aggregation_network.pt'

First of all, thank you very much for your work. You've done an excellent job.I would like to ask if you can give the file of this weight. weights/aggregation_network.pt.

Hi! Thanks for your kind comments. You can download the weights from our servers. In the root folder diffusion_hyperfeatures, run:
mkdir weights
wget http://diffusion_hyperfeatures.berkeleyvision.org/weights/aggregation_network.pt -O weights/aggregation_network.pt


feat/auth via supabase

This PR adds authentication using Supabase. All that use supabase are now under /api/v3/[get|delete|post].
We still support the auth using auth0 for a smoother transistion. The api can already be found under https://supabase.api.giessdenkiez.de/
This is a major refactor. I know but we need this to reuse code in routes

@all-contributors @julizet for review

@all-contributors add @julizet for review