_WriteBuildWasmBootJsonFile is not incremental #129280

Activity

1. jjonescz

   added

   area-Build-mono

   on Jun 11, 2026
2. dotnet-policy-service

   added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jun 11, 2026
3. jjonescz

   added

   arch-wasmWebAssembly architectureWebAssembly architecture

   on Jun 11, 2026
4. dotnet-policy-service commented on Jun 11, 2026

   

   dotnet-policy-servicebot

   on Jun 11, 2026 – with Dotnet Policy Service

   Contributor

   More actions

   Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
   See info in area-owners.md if you want to be subscribed.
5. jjonescz

   added

   os-browserBrowser variant of arch-wasmBrowser variant of arch-wasm

   on Jun 11, 2026
6. oroztocil

   assigned

   maraf

   on Jun 11, 2026
7. oroztocil

   added

   investigate

   and removed

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Jun 11, 2026
8. akoeplinger

   added this to the 11.0.0 milestone on Jun 11, 2026
9. maraf commented on Jun 12, 2026

   

   maraf

   on Jun 12, 2026

   Last edited by maraf

   Member

   More actions

   Related to #125367
10. lewing commented on Jun 18, 2026

    

    lewing

    on Jun 18, 2026

    Member

    More actions

    Adding evidence from a downstream variant of this same bug, surfaced by a different test path.

    Investigating WBT Wasm.Build.Tests.WasmTemplateTests.TypeScriptDefinitionsCopiedToWwwrootOnBuild(config: Debug, emitTypeScriptDts: True) failure on PR #129454 (build 1470806, workitem WBT-NoWebcil-MONO-ST-Wasm.Build.Tests.WasmTemplateTests). The reported failing target there is one level downstream:

    Building target "_BuildCopyStaticWebAssetsPreserveNewest" partially, because some output files are out of date with respect to their input files.
    [_BuildStaticWebAssetsPreserveNewest:
      Input  = obj\Debug\net11.0\compressed\{hash}-{0}-{fp}-{fp}.gz,
      Output = bin\Debug\net11.0\wwwroot\_framework\dotnet.{fp}.js.gz]
    Input file is newer than output file.
    

    Chain of causation (binlog-verified)

    1. _WriteBuildWasmBootJsonFile runs GenerateWasmBootJson (uses ArtifactWriter.PersistFileIfChanged — preserves old mtime on unchanged content) followed by <Touch Files="$(_WasmBuildBootJsonPath)" />. The Touch bumps obj/.../dotnet.js mtime to current.
    2. Same obj/.../dotnet.js is a source for the StaticWebAssets compression pipeline (GenerateBuildCompressedStaticWebAssets → GZipCompress task in dotnet/sdk src/StaticWebAssetsSdk/Tasks/Compression/GZipCompress.cs).
    3. In the -question rebuild, _WriteBuildWasmBootJsonFile correctly skips (UpToDate). But GenerateBuildCompressedStaticWebAssets has no Inputs=/Outputs= declaration, so its body runs unconditionally. GZipCompress's internal check (input.mtime < output.mtime strict) treats equal/newer as "compress" and re-writes obj/.../{0}.gz:

       Compressing 'obj\Debug\net11.0\dotnet.js' because file is newer than
       'obj\Debug\net11.0\compressed\{hash}-{0}-{fp}-{fp}.gz'.
       

    4. That re-written .gz now has a fresh mtime, exceeding the bin/.gz (last written during build WIP: repo consolidation scouting kick-off - make clr build locally on Windows #1's Copy). _BuildCopyStaticWebAssetsPreserveNewest sees its declared input newer than its declared output → -question fails.

    This is the symmetric symptom to what you reported: same root (<Touch> on the boot JSON, introduced by #125367), just the cascade extending one target further into the StaticWebAssets pipeline. Same fix addresses both.

    Historical context

    Worth noting: PR #118637 (Aug 2025, "Override boot config only when the content changes") was originally added specifically to fix the _BuildCopyStaticWebAssetsPreserveNewest symptom in dotnet/aspnetcore#63207 — by introducing PersistFileIfChanged so dotnet.js mtime would only change on content change. #125367's <Touch> undid that protection.

    Fix

    PR #129591 — touch a separate wasm-bootjson-{build,publish}.complete.stamp instead of the boot JSON itself, and use the stamp as the target's Outputs=. MSBuild's I/O check on the boot-JSON target works correctly via the stamp, while the boot JSON's mtime stays content-derived (restoring #118637's invariant for downstream consumers).

    Both build and publish targets get the same treatment in that PR.

    Note

    This comment was AI/Copilot-generated.
11. lewing

    closed this as completedin #129591on Jun 22, 2026
12. lewing

    added a commit that references this issue on Jun 22, 2026

    [browser] Wasm boot JSON: touch a stamp, not the boot JSON itself (fix …

    ...

    This issue will close once commit 7f00936 is merged into the 'main' branch.

    7f00936
13. eiriktsarpalis

    added a commit that references this issue on Jul 15, 2026

    [browser] Wasm boot JSON: touch a stamp, not the boot JSON itself (fix …

    ...

    This issue will close once commit 591de2b is merged into the 'main' branch.

    591de2b
14. github-actions

    locked and limited conversation to collaborators on Jul 23, 2026