Create minimal repro for AOT Blazor memory issue

[StachuDotNet]

https://github.com/darklang/dark/pull/4070 introduced a "magic" line of code. Figure out how it helps, create a minimal repro for the .NET team, and send it to them.

Also, try using .Result instead of Task.map.

[StachuDotNet]

This issue was made assuming #4070 would solve our problem; it was insufficient. I'm having to create a minimal repro as part of #4059; closing this in favor of that.

[StachuDotNet]

https://github.com/StachuDotNet/ply-aot-serialization-bug-repro

Can still be thinned out a bit, but this is a pretty-minimal repro. Going to trim it a bit further, then figure out who to ping. Ply? STJ? FSharp.STJ? .NET?

[StachuDotNet]

still feels like the 'depth' of the AST really matters.

[StachuDotNet]

I've thinned this out quite a bit, in that repo. Most important parts are here and here.

While we're past it mattering in Dark[1], it's gonna bug me until I figure out what's wrong.

• if I remove a let from the expression, it works.
• if I use a non-Ply task, it works
• if I use non-published builds, it works.
• if I flip AOT off, it works (even in published builds)
• if I try to simplify the types further (and adjust the payload accordingly), it works
• if I increase the number of lets, it works.
• if I remove one of the pipes, it works

[1] - we chose the "use a non-Ply task" option.

Feeling like I've no idea what the problem is, still, somehow :)

[pbiggar]

Probably the blazor people would be interested in this. If it turns out not to be a fault of blazor, they are best positioned to tell the library what they're doing wrong (though the most likely thing is nothing, cause it's supposed to be a managed language unless they're doing native stuff).

[StachuDotNet]

I wrote a really long Issue. If you have a few minutes to review and edit it, I'd highly appreciate. Thinking to post to aspnet repo upon review.

• [ ] paste picture and text of the actual error message
• [ ] fix+add some links

[StachuDotNet]

I've recently encountered an odd bug.

A repository has been created to demonstrate a "minimal" reproduction, yet it's difficult to pinpoint the exact issue. Roughly, though: I encounter a "..." error when calling some Blazor-AOT-compiled published code, but don't encounter the bug when working with non-published or non-AOT artifacts.

The original finding of the error involved a very large payload, so I mistakenly assumed that we were hitting some memory limit due to the large payload. Since then, I've thinned the bug down to a thin separate repo, including a much smaller payload - so that's not the issue.

Within that repo is:

• a wasm project
  • project type: F#, Microsoft.NET.Sdk.BlazorWebAssembly, AOT-built
  • imports 3 NuGet packages
  • FSharp.SystemTextJson, for a JsonFSharpConverter used in System.Text.Json deserialization, to deserialize F# Unions and Records
  • Ply; an F#-specific task abstraction
  • Microsoft.AspNetCore.Components.WebAssembly
  • exposes an EvalWorker type with an `OnMessage(message:string) public static async member
  • IO: to be called by a webpage, after having Blazor loaded
  • what it does: receives a message: string, deserializes it to a Payload type, and ends in a Ply task
• a webhost project
  • project type: F#, Microsoft.NET.Sdk.Web
  • purpose: to host some static assets
  • an index.html file - more on that later
  • the non-published output of the wasm project
  • the published output of the wasm project
• a demo.sh that builds wasm, copies its output to folders in webhost/wwwroot/blazor

.NET SDK version is 6.0.300, running on Ubuntu, tested in Chrome and Firefox.

The relevant pieces are mostly within [webhost/index.html]() and [wasm/Program.fs]().

• index.html loads in browser, references blazor.webassembly.js with autostart="false" so it doesn't automatically try and load Blazor
• index.html manually loads Blazor, ensuring it loads the right output of wasm (either publish or nonpublish subfolder of webhost/wwwroot/blazor)
• once Blazor has loaded, it makes a binding to the exposed EvalWorker.OnMessage member, and call the resultant handler with a very specific payload
• Wasm.fs takes that input payload, attempts to deserialize it with System.Text.Json, and:
  • in non-AOT or non-published builds: succeeds
  • in published AOT builds: suceeds, then fails

I'm not sure what party the issue is coming from. It could be any of: .NET/Blazor/mono, Ply, System.Text.Json, FSharp.SystemTextJson. My hunch is that it's either FSharp.SystemTextJson or Ply, but since taking any any of the pieces makes the error go away:

• if I remove any ELet or EPipe from the nested expression in index.html, it works
• if I increase the number of lets, it works.
• if I use a non-Ply task (i.e. remove FSharp.Control.Tasks.Affine.), it works
• if I use non-published builds, it works.
• if I flip AOT off, it works (even in published builds)

FWIW, this is not blocking me in any way - we decided to use a non-Ply task{} instead of the Ply one, and have gotten past the issue. I hope that this is the best repo to start here - I'm getting the error only in published AOT builds, so getting to the bottom of "why" there is a good place to start.

[StachuDotNet]

Actually, I'll just manage the issue here: https://github.com/StachuDotNet/ply-aot-serialization-bug-repro/issues/1

and other parties can link to it; easier to pass around this way.

[pbiggar]

Ill post my thoughts here to avoid dirtying up your pristine bug:

• does it only happen in a web worker? or also in regular browser global context
• does it happen using the standard .net blazorworker.js (I forget whether we're using that or not)

[StachuDotNet]

The separate repo is using the out-of-the-box blazor.webassembly.js, no webworker / custom blazorworker.

[StachuDotNet]

Feel free to post there - I'm just so damn curious what it is. That said, beyond posting it to aspnetcore tomorrow, I'll let it settle for a few days, as I'm tired of chasing it.