feat(Async): RunSynchronouslyImmediate by bartelink · Pull Request #19804 · dotnet/fsharp

bartelink · 2026-05-25T17:55:27Z

Implements RunSynchronouslyImmediate per fsharp/fslang-suggestions#1042

Checklist

Test cases added
- validate absence of thread hops
- contrast with Async.RunSynchronously
xmldoc updated
- mention RSI in RS
- mention RS in RSI
- mention fact SynchronizationContext is not honored in RSI
- mention RS ensures you're on a threadpool thread
- DONT mention RSI does not force you onto a threadpool thread - my assumption is that RS does that for esoteric reasons we don't need to bother users of RSI with?
Release notes entry updated

github-actions · 2026-05-25T17:56:11Z

❗ Release notes required

You can open this PR in browser to add release notes: open in github.dev

✅ Found changes and release notes in following paths:

Change path Release notes path Description

src/FSharp.Core docs/release-notes/.FSharp.Core/11.0.100.md

src/Compiler docs/release-notes/.FSharp.Compiler.Service/11.0.100.md

Copilot

Pull request overview

Adds Async.RunSynchronouslyImmediate to FSharp.Core to allow running an Async<'T> synchronously while always executing the initial step on the calling thread (aimed at improved diagnostics/stack traces in FSI/tests), with accompanying API surface updates, documentation, unit tests, and release notes.

Changes:

Add public API Async.RunSynchronouslyImmediate and wire it through Async primitives.
Add unit tests characterizing basic behavior and key differences vs Async.RunSynchronously.
Update FSharp.Core surface area baselines and release notes; extend XML docs for RunSynchronously/RunSynchronouslyImmediate.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/AsyncModule.fs	Adds unit tests for `RunSynchronouslyImmediate` and contrasts with `RunSynchronously`.
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard21.release.bsl	Records new public surface area entry for `RunSynchronouslyImmediate`.
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard21.debug.bsl	Records new public surface area entry for `RunSynchronouslyImmediate`.
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard20.release.bsl	Records new public surface area entry for `RunSynchronouslyImmediate`.
tests/FSharp.Core.UnitTests/FSharp.Core.SurfaceArea.netstandard20.debug.bsl	Records new public surface area entry for `RunSynchronouslyImmediate`.
src/FSharp.Core/async.fsi	Adds XML docs for the new API and revises `RunSynchronously` docs to reference it.
src/FSharp.Core/async.fs	Implements the new API by exposing an “immediate” synchronous runner and refactoring `RunSynchronously` internals.
docs/release-notes/.FSharp.Core/11.0.100.md	Adds release note entry for `Async.RunSynchronouslyImmediate`.

Comments suppressed due to low confidence (1)

tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/AsyncModule.fs:527

This test uses a raw Thread but doesn’t capture exceptions from the thread body. Any unexpected exception inside the thread (including from Async.RunSynchronously) will be unhandled and may crash the test process rather than reporting a normal xUnit failure. Capture exceptions in the thread and rethrow/assert after Join.

        let t = Thread(fun () ->
            callerThreadId <- Thread.CurrentThread.ManagedThreadId
            async { runSyncThreadId <- Thread.CurrentThread.ManagedThreadId }
            |> Async.RunSynchronously
            async { immThreadId <- Thread.CurrentThread.ManagedThreadId }
            |> Async.RunSynchronouslyImmediate)

bartelink · 2026-05-26T11:28:21Z

@T-Gro I've implemented as per OP of fsharp/fslang-suggestions#1042

Firstly, in a debugger context a first chance exception breakpoint has more direct causation vs having to disentangle an adjacent thread waiting, which tooling may or may not be able to convey unaided.

However, while the exception stack trace has less noise, it's not significantly better AFAICT:

It seems the TL;DR value prop is:

in a debugger breakpoint there's an obvious call stack
stack traces have 2/3 less noise layers
default perf is better as no egregious thread hops (though for many real world cases, there may be a root RunSynchronously that pays the hop price and then nested calls don't pay?)

But its not a slam dunk as:

potential deadlocks
confusion about a longstanding thing that people's fingers and thousands of tutorials had

This is making me think I should dial back the xmldoc from where I have it trying to set a "use the new RunSynchronouslyImmediate in FSI from now on" vibe (as I've tried to do with AwaitTask vs Await where it is a slam dunk)

Final stacktrace comparison:

cc @majocha @dsyme

Copilot

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 9 comments.

bartelink · 2026-05-26T22:22:15Z

    /// Run the asynchronous workflow and wait for its result.
    [<DebuggerHidden>]
-    let QueueAsyncAndWaitForResultSynchronously (token: CancellationToken) computation timeout =
+    let QueueAsyncAndWaitForResultSynchronously computation (token: CancellationToken) timeout =


can revert this, but trying to get arg order consistent across most involved functions

bartelink · 2026-05-26T22:22:52Z

-                    trampolineHolder
-                    (fun res -> resultCell.RegisterResult(AsyncResult.Ok res, reuseThread = true))
-                    (fun edi -> resultCell.RegisterResult(AsyncResult.Error edi, reuseThread = true))
-                    (fun exn -> resultCell.RegisterResult(AsyncResult.Canceled exn, reuseThread = true))


old behavior resulting in OperationCanceledException

does it change RunSynchronously implementation?

@majocha in the PR as it stands, the core impl of RunSynchronouslyImmediate is:
https://github.com/bartelink/fsharp/blob/013acc1fca33bdfcd6f978d531bc0c6e1e34c199/src/FSharp.Core/async.fs#L1157

that new code is based on OP of Add Async.RunImmediate fsharp/fslang-suggestions#1042 (comment)

RunSynchronously used to delegate to https://github.com/dotnet/fsharp/pull/19804/changes#diff-7045116fe4610c3375ffcdd7df2ee411e71879bdf25890c8d3cf047c1b5208e2L1141 where conditions allow (no thread hop required)

RunSynchronously now delegates to 1

The key diff is that:

the old way with the ResultCell Commit would result in OperationCanceledException being observed by caller if cancellation happened during running

the new way is tcs.Task.GetAwaiter().GetResult(), which results in a TaskCanceledException (which, to the best of my knowledge does not provide a way to wire in the CT info)

The pros from my perspective are:

RSI is simple and direct and matches the OP, without coupling to ResultCell

if/when we ever get to split RunSynchronously into orthogonal easy to explain concepts and/or methods then those impls will tie to more ubiquitous things like TaskCompletionSource

nobody needs to debug or reason about actual RSI vs the RSI-but-with-ResultCell-via-RS differences

Not an easy call, which is why I'm looking for someone else to vouch for it!

bartelink · 2026-05-26T22:25:37Z

            computation
        |> unfake

-    [<DebuggerHidden>]


moved up as required by RunSynchronously

note the whole PR could be made much shorter by having the Async layer call Async.FromContinuations

However, as mentioned in other places, I believe its for the best that RunSynchronouslyImmediate and the immediate path of RunSychronously should have strong clear ties in the lower layer as this PR does

bartelink · 2026-05-27T11:22:49Z

The open review comments and Don's comment here fsharp/fslang-suggestions#1042 (comment) make me think:

implementing RunSynchronouslyBackground (fka RunImmediateExceptOnUI) might make it easier to explain the overall set of APIs, i.e.

RSI guarantees inline running (but also potentially introduces synccontext deadlock)
RSB = RSI + offloads iff necessary to avoid synccontext deadlock

But, there's only one consumer of RSB atm, so what is the cut and dried use case. i.e. what would the summary/release notes say to convey who needs this API and when?

if you had RSI+RSB and leave RS as-is (changing its behavior or guarantees is presumably not tenable), what new APIs with individual orthogonal behaviors would you add with a view to having better alternatives and then effectively deprecating RS?

Perhaps a RunSynchronouslyTimeout with a mandatory timeout parameter?

runs in threadpool unconditionally

provides some clear semantics that resolves the puzzle of what is being achieved / silently left unhandled in

fsharp/src/FSharp.Core/async.fs

Lines 1508 to 1512 in 7d5c771

    
           let timeout, cancellationToken = 
        
               match cancellationToken with 
        
               | None -> timeout, defaultCancellationTokenSource.Token 
        
               | Some token when not token.CanBeCanceled -> timeout, token 
        
               | Some token -> None, token

+

fsharp/src/FSharp.Core/async.fs

Lines 1121 to 1138 in 7d5c771

    
           match res with 
        
           | None -> // timed out 
        
               // issue cancellation signal 
        
               if innerCTS.IsSome then 
        
                   innerCTS.Value.Cancel() 
        
               // wait for computation to quiesce; drop result on the floor 
        
               resultCell.TryWaitForResultSynchronously() |> ignore 
        
               // dispose the CancellationTokenSource 
        
               if innerCTS.IsSome then 
        
                   innerCTS.Value.Dispose() 
        
               raise (TimeoutException()) 
        
           | Some res -> 
        
               match innerCTS with 
        
               | Some subSource -> subSource.Dispose() 
        
               | None -> () 
        
               res.Commit()

+

fsharp/src/FSharp.Core/async.fs

Lines 1163 to 1165 in 7d5c771

    
           match SynchronizationContext.Current, Thread.CurrentThread.IsThreadPoolThread, timeout with 
        
           | null, true, None -> RunImmediate cancellationToken computation 
        
           | _ -> QueueAsyncAndWaitForResultSynchronously cancellationToken computation timeout

should the API take an outer CT and/or defaults to DefaultCancellationToken?
what happens if the token is cancelable and you wanted a timeout?
can the default one not be cancelable

In general I think one PR that adds one API is a perfectly fine outcome for now, but if someone out there (@dsyme ?) has a really clear picture of all the use cases, it may be worth at least speccing out in full the orthogonal elements of what only the current impl of RunSynchronously provides that are not covered by RSI+RSB

In short, if someone is convinced that RSI + RSB and/or some complementary APIs makes it possible to deprecate and eventually move away from from a complected RunSynchronously, I'm happy to do the work, but I don't feel I understand it deeply enough atm.

majocha · 2026-05-27T12:05:50Z

FWIW my limited experience with internal RunImmediate implemented in a few places in this repo: It can cause problems in unexpected places, IIRC there were some deadlocks when trying to parallelize tests. As noted, it only improves debugger call stacks. Exception stack traces - not that much.

T-Gro · 2026-06-04T12:02:41Z

@bartelink :
re: RunSynchronously - Deprecating it now would be I guess too early, but maybe we can at least start with a "See also .." remark in the XML docs (which then make it to the published docs).

And consider marking it obsolete later in a separate PR.

What RunSynchronously provides is the automated decision-making based on inputs+context. Even though it can be handy when writing library code (that does not know where/how it will be run), it does go against the "Pit of success" spirit.

bartelink · 2026-06-04T12:25:46Z

but maybe we can at least start with a "See also .." remark in the XML docs (which then make it to the published docs).

Will double check we have an xmldoc cross reference (think we do already)

I don't think it's practical to actually make RunSynchronously literally Obsolete in even the medium term (esp considering that blind replacement will lead to deadlocks, and per Murphy's Law, those will be in lots of low traffic places like try ... with handling etc.

Let me know if there's anything else to do to get this completely ready for whenever merge makes sense.

What RunSynchronously provides is the automated decision-making based on inputs+context. Even though it can be handy when writing library code (that does not know where/how it will be run), it does go against the "Pit of success" spirit.

See also fsharp/fslang-suggestions#1042 (comment) - maybe a pathway can be that there is a camelCase Async.* helper that uses RSI and shouts "pick me" for fsi/tests cases?

T-Gro

one last review round

T-Gro · 2026-07-11T07:18:33Z

+            (fun edi -> tcs.SetException edi.SourceException)
+            // NOTE In this case, cancellation will surface as a TaskCanceledException (with CT.None) from GetResult()
+            //      (as opposed to the OperationCanceledException that RegisterResult cancellation ends up mapping to)
+            (fun _operationCanceledExn -> tcs.SetCanceled())


This ccont also backs RunSynchronously's inline fast-path (L1175), so the token gets stripped there:

try Async.RunSynchronously(comp, cancellationToken = myTok) with | :? OperationCanceledException as e when e.CancellationToken = myTok -> fallback | :? OperationCanceledException -> reraise ()

inline (thread-pool caller): token stripped -> reraise() -- wrong branch

queued (other caller): token kept -> fallback

same call, thread-dependent

- (fun _operationCanceledExn -> tcs.SetCanceled()) + (fun operationCanceledExn -> tcs.SetException operationCanceledExn)

Then the test at AsyncModule.fs:470 flips: Assert.Throws<TaskCanceledException> -> Assert.Throws<OperationCanceledException>.

this leaves the internal tcs.Task Faulted not Canceled — invisible here (immediately GetResult()'d, only the thrown exception escapes)

SetCanceled(token) (keeps both) is .NET 5+, absent on ns2.0/2.1, so SetException is the only token-preserving option

applied this change
See also clones in 8422a23 (all call sites identical, though obviously there's potential for effects from the breaking nature of the change)

see also related comment thread #19804 (comment)

(All impls of RSI, and the RS shortcut path are now identical, and the test documenting the behavior change has become a pinning test validating that it's OperationCanceledException with the triggering token)

T-Gro · 2026-07-11T07:18:33Z

 open Xunit
 open FSharp.Test.Utilities

+#if !FSHARPCORE_USE_PACKAGE // TODO For 11.x, remove shimming to rely fully on shipped FSharp.Core variant


Guard is inverted (illib.fs defines the shim when the package lacks the member).

async { return 42 } |> Async.RunSynchronouslyImmediate // FSHARPCORE_USE_PACKAGE=true (BUILDING_USING_DOTNET default)

package = shipped 10.0.101, no such member

shim also excluded by the ! -> FS0039

green CI only builds the in-repo config

-#if !FSHARPCORE_USE_PACKAGE +#if FSHARPCORE_USE_PACKAGE

applied this change but it breaks MacOS build so have temporarily reinstated

@T-Gro I have not managed to get to the bottom of this as to be honest I don't understand the full array of build scenarios.

(Not saying you don't have a point; it's just that in practice my programming-by-coincidence had a purpose!)

Bottom line is I applied it and it broke the build, and reverting it made it green

I'm happy for you to either try to resolve it by working in this branch or providing me some more suggestions

T-Gro · 2026-07-11T07:18:33Z

 // This file mimics how Roslyn handles their compilation references for compilation testing
 module Utilities =

+#if !FSHARPCORE_USE_PACKAGE // TODO For 11.x, remove shimming to rely fully on shipped FSharp.Core variant


Same inverted guard as Common.fs:19 -> breaks package-mode build (FSHARPCORE_USE_PACKAGE=true, the BUILDING_USING_DOTNET default) with FS0039.

-#if !FSHARPCORE_USE_PACKAGE +#if FSHARPCORE_USE_PACKAGE

Applied and then reverted as per common.fs:19

T-Gro · 2026-07-11T07:18:33Z

-        ///
-        /// The timeout parameter is given in milliseconds.  A value of -1 is equivalent to
-        /// <see cref="F:System.Threading.Timeout.Infinite"/>.
+        /// <summary><p>Runs the asynchronous computation on a threadpool thread, honoring the ambient


SynchronizationContext.SetSynchronizationContext ctx async { return 1 } |> Async.RunSynchronously // ctx.Post called 0 times; runs inline

"on a threadpool thread" -- false (fast-path is inline)

"honoring the ambient SynchronizationContext" -- false (never posts)

- /// <summary>Runs the asynchronous computation on a threadpool thread, honoring the ambient - /// <see cref="T:System.Threading.SynchronizationContext"/>. + /// <summary>Runs the computation and blocks the caller until it completes. Runs inline on the + /// calling thread when it is a thread-pool thread with no ambient SynchronizationContext and no + /// timeout; otherwise runs on the thread pool.

Your wording feels much better (I was aware that my wording was technically not 100% correct - my aim was to emphasize the core difference vs RSI: even if you are doing something tiny, you'll incur a thread hop more often than you might expect from the name).

Also wanted to be pedantic on some specifics:

on a threadpool thread" -- false (fast-path is inline)

but fast path requires you to already be on a thread pool thread. So RunSynchronously didnt need to do a hop, but the code is run on a thread pool thread?

"honoring the ambient SynchronizationContext" -- false (never posts)

I think this is due to special casing triggered by the reuseThread = true parameter to RegisterResult (async.fs: 1004)

But I may well have missed the point you're trying to make.

Happy to apply your summary assuming all the above tallies with your understanding/intent.

T-Gro · 2026-07-11T07:18:33Z

+        /// </p>
+        /// <p>Does not support a timeout; see
+        /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.RunSynchronously`1"/> if one is desired.</p>
+        /// <p>Does not ensure execution takes place on a threadpool thread; see


async { return 1 } |> Async.RunSynchronously // also runs inline -- not a threadpool guarantee

cross-ref to RunSynchronously here implies a threadpool guarantee it doesn't provide

- /// Does not ensure execution takes place on a threadpool thread; see - /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.RunSynchronously`1"/> or - /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.SwitchToThreadPool"/> if this is required. + /// Does not ensure execution takes place on a threadpool thread; see + /// <see cref="M:Microsoft.FSharp.Control.FSharpAsync.SwitchToThreadPool"/> if this is required.

The key driver for me referring to both was to try to explain the key behavioral difference of consequence between RS and RSI in terms of other concrete methods as a pedagogical mechanism.

AIUI (but I may very well be wrong) RunSynchronously does provide this guarantee, as which:

stays on current thread until the first asynchronous suspension if all these things are true:

the current thread is a threadpool thread

and SynchronizationContext.Current is null

and we're not trying to apply a timeout

in all other cases it posts the work into the thread pool and uses the calling thread to await

Note I renamed the internal impl to RunSynchronouslyBackgroundThreadPool to try to convey the above semantics in shorthand.

All of that said, clearly my wording didn't get the point across as intended.

Hence I feel it may make more sense to reword it and/or remove it entirely as the proposed change turns it into a non-sequitur as the sentence no longer enables people to triangulate/bridge the concepts as intended?

T-Gro · 2026-07-11T09:17:03Z

Sorry for the late replies. Decisions:

what is the cut and dried use case [for RSB]?

It's internal-only — replace its single call site with RunSynchronously. No new API.

a camelCase Async.* helper that shouts "pick me"?

Third name is too much here, let's avoid it.

Ship RSI alone, RS unchanged + "see also". Merge-ready once the two blockers in my review land (inverted #if guard; cancellation dropping the token).

…mmediate

bartelink · 2026-07-13T15:02:22Z

@T-Gro I believe this is ready for re-review; feel free to mark comment threads as resolved as you read them.

Happy to address any follow-ups later and/or tomorrow

github-project-automation Bot added this to F# Compiler and Tooling May 25, 2026

github-project-automation Bot moved this to New in F# Compiler and Tooling May 25, 2026

bartelink force-pushed the run-synchronously-immediate branch 2 times, most recently from d6a0470 to 69e41a2 Compare May 25, 2026 22:07

bartelink marked this pull request as ready for review May 25, 2026 22:19

bartelink requested a review from a team as a code owner May 25, 2026 22:19

Copilot AI review requested due to automatic review settings May 25, 2026 22:19

Copilot started reviewing on behalf of bartelink May 25, 2026 22:19 View session

Copilot AI reviewed May 25, 2026

View reviewed changes

Comment thread tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/AsyncModule.fs Outdated

Comment thread src/FSharp.Core/async.fsi Outdated

Comment thread src/FSharp.Core/async.fsi Outdated

Comment thread src/FSharp.Core/async.fsi Outdated

github-actions Bot added the AI-Tooling-Check-Scanned-Clean Tooling check: diff analyzed, no interesting infrastructure files label May 25, 2026

T-Gro reviewed May 26, 2026

View reviewed changes

Comment thread src/FSharp.Core/async.fsi Outdated

T-Gro reviewed May 26, 2026

View reviewed changes

Comment thread src/FSharp.Core/async.fsi Outdated

bartelink mentioned this pull request May 26, 2026

Add Async.RunImmediate fsharp/fslang-suggestions#1042

Open

5 tasks

bartelink commented May 26, 2026

View reviewed changes

Comment thread src/FSharp.Core/async.fs Outdated

bartelink force-pushed the run-synchronously-immediate branch from 75fed30 to f9e0383 Compare May 26, 2026 15:40

bartelink commented May 26, 2026

View reviewed changes

Comment thread src/FSharp.Core/async.fs

bartelink requested review from T-Gro and Copilot May 26, 2026 21:31

Copilot AI reviewed May 26, 2026

View reviewed changes

bartelink commented May 26, 2026

View reviewed changes

Comment thread tests/FSharp.Core.UnitTests/FSharp.Core/Microsoft.FSharp.Control/AsyncModule.fs

bartelink commented May 27, 2026

View reviewed changes

Comment thread src/FSharp.Core/async.fs

T-Gro added the AI-reviewed PR reviewed by AI review council label May 27, 2026

bartelink added 8 commits June 5, 2026 20:08

feat(Async): RunSynchronouslyImmediate

42e2a8d

Doc polish / characterization tests

5240c49

copilot Code review changes

0e6b507

RunSynchronouslyImmediate2

a085f84

Remove duplication

ef47597

diff reduction

89575ee

heavily revise xmldoc

8cbbbb4

Address copilot review

5074cab

bartelink force-pushed the run-synchronously-immediate branch from 013acc1 to 5074cab Compare June 5, 2026 19:25

bartelink added 4 commits June 5, 2026 20:57

rename Compiler.Service.Tests RI

4d26acf

rename FSharp.Test.Utilities RI

2b1e1fc

rename Compiler RI

ea790f5

unify shims

ca1b254

bartelink force-pushed the run-synchronously-immediate branch from 331b0b6 to 71c8638 Compare June 5, 2026 20:48

CL

d1c658a

bartelink force-pushed the run-synchronously-immediate branch from 71c8638 to d1c658a Compare June 5, 2026 20:50

Remove shimming condition

dff9ed1

T-Gro reviewed Jul 11, 2026

View reviewed changes

bartelink added 7 commits July 11, 2026 17:51

Merge remote-tracking branch 'upstream/main' into run-synchronously-i…

f7cd0e0

…mmediate

fix: Correct guard on RunSynchronouslyImmediate polyfill

0a7eb30

chore: polish release notes

70bd071

fix: Correct behavior change per review

172d6cd

chore: Sync shim impls of RSI

8422a23

chore: Unmangle refactoring diff

3393014

temp: unflip guard

ed96e84

Uh oh!

Conversation

bartelink commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Checklist

Uh oh!

github-actions Bot commented May 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

❗ Release notes required

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

bartelink commented May 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bartelink May 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bartelink commented May 27, 2026

Uh oh!

majocha commented May 27, 2026

Uh oh!

Uh oh!

T-Gro commented Jun 4, 2026

Uh oh!

bartelink commented Jun 4, 2026

Uh oh!

T-Gro left a comment

Choose a reason for hiding this comment

Uh oh!

T-Gro Jul 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bartelink Jul 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bartelink commented May 25, 2026 •

edited

Loading

github-actions Bot commented May 25, 2026 •

edited

Loading

bartelink commented May 26, 2026 •

edited

Loading

bartelink May 27, 2026 •

edited

Loading

T-Gro Jul 11, 2026 •

edited

Loading

bartelink Jul 11, 2026 •

edited

Loading

bartelink Jul 11, 2026 •

edited

Loading