fix: Ensure PlatformScheduleAction order is preserved

[jsonbailey]

In Android/iOS these action are run on the main thread whereas in netstandard they are run in a thread pool and are not guaranteed to be run in order when we don't wait for the result.

---

Note

Ensure scheduled actions run in order on netstandard by chaining them via a shared Task instead of using Task.Run.

• Async scheduling (netstandard) in pkgs/sdk/client/src/PlatformSpecific/AsyncScheduler.netstandard.cs:
  • Introduce private static volatile Task _lastScheduledTask = Task.CompletedTask.
  • Replace Task.Run(a) with chaining: _lastScheduledTask = _lastScheduledTask.ContinueWith(_ => a()); to enforce ordered, fire-and-forget execution.

^{Written by Cursor Bugbot for commit e0169d4. This will update automatically on new commits. Configure here.}

[kinyoklion]

Do we need a timeout here? Or do we already not timeout, and require the application code return in a timely manner?

[tanderson-ld]

I think any amount of wait violates the AsyncScheduler contract, no?

[kinyoklion]

True, this probably isn't good on the caller side of the equation. It still does feel like we need a thread specifically to wait for these tasks, or a pool of 1 that we just submit to.

[tanderson-ld]

Perhaps a queue of tasks that get linked together as added and the next is dispatched as the previous finishes?

[kinyoklion]

Yeah, that works as well, potentially very similar to the async queues we've implemented for the CSI spec.

[jsonbailey]

I've updated it to be a chained list of calls. The continueWith should still work even if an action throws an exception. This should allow us to keep the same contract but enforce the order.

[cursor]

Bug: Non-Atomic Task Scheduling Causes Concurrency Issues

The read-modify-write operation on _lastScheduledTask in PlatformScheduleAction is not atomic. Concurrent calls can read the same task, create parallel continuations, and overwrite each other's assignments. This breaks the ordering guarantee, causing actions to run concurrently instead of sequentially, and potentially losing some from the chain.

 

[cursor]

Bug: Race Condition in Task Scheduler

There's a race condition in PlatformScheduleAction. Concurrent calls can cause _lastScheduledTask to be updated non-atomically, which breaks the intended sequential ordering of scheduled tasks. This means tasks may execute out of order or in parallel, as volatile doesn't ensure atomicity for read-modify-write operations.