dotnet / dotnet/msbuild

TaskParameterEventArgs may read items after a delay, after they've been mutated

Open
#6,704 0 comments 1 reaction 1 assignee Claimed by @KirillOsenkov View on GitHub
Area: Logging triaged
Dominant language
C#
Stars
5.5k
Forks
1.5k
Avg merge
1d 8h
Merged PRs (30d)
141

Description

I'm investigating a case where the `AssignProjectConfiguration` task has logged input `ProjectReference` items that shows the `BuildReference` and `ReferenceOutputAssembly` metadata.

However that metadata is actually being set within the task itself, which tells me that [LogTaskParameter](https://source.dot.net/#Microsoft.Build/BackEnd/Components/RequestBuilder/IntrinsicTasks/ItemGroupLoggingHelper.cs,5eb3bbf5a68d102b) is capturing the array of items to log, but doesn't actually log them until either the `TaskParameterEventArgs` is being serialized to be sent to the central node, or actually sent to the logger (both are asynchronous).

For proof I've inserted a new Print target immediately before AssignProjectConfiguration:
![image](https://user-images.githubusercontent.com/679326/126738205-de7ea04d-ebed-4cff-ae1d-82d743352840.png)

But when logging the task parameters for AssignProjectConfiguration it already contains the metadata:
![image](https://user-images.githubusercontent.com/679326/126738258-6dcd6a06-1d3e-4fe6-b14c-6c6dc9a0c819.png)

Which tells me that when the items are mutated by the task we observe that.

Aren't they backed by an immutable data structure? Could we take a snapshot of that? I'm afraid if not, we'll have to allocate to create an immutable snapshot at the moment of logging, and these allocations are huge and really undesirable. We'll lose a lot of hard won ground in performance and memory growth.

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.