glue-task-manager

name	glue-task-manager
description	TaskManager's task-scheduling model — priority tiers, not FIFO, and why AddOrMoveToEnd coalescing can silently miss. Triggers: TaskExecutionPreference, AddOrMoveToEnd, TaskManager.Self.Add/AddAsync, GenerateElementCode, AddOrRunIfTasked, EffectiveId, out-of-order regeneration.

Glue TaskManager Scheduling

FRBDK/Glue/Glue/Tasks/TaskManager.cs runs almost all project-mutating work through one dedicated thread and a priority queue (taskQueue), not a FIFO queue. glue-unit-test-bootstrap's "Sibling seams" section covers the SynchronousMode test seam that collapses this to inline sequential execution — which is why ordering bugs here are invisible under that mode and need a real (non-synchronous) queue to pin.

Tiers beat enqueue order

TaskExecutionPreference (Asap / Fifo / AddOrMoveToEnd) are fixed numeric tiers far apart (0, ulong.MaxValue/3, 2*ulong.MaxValue/3); taskoffset only breaks ties within a tier. A Fifo task queued after an AddOrMoveToEnd task still runs first, unconditionally. GenerateElementCode (GenerateCodeCommands.cs) deliberately queues its file-write + .csproj-registration work at AddOrMoveToEnd to keep the UI responsive — so any operation that depends on that codegen having already landed (moving or deleting the files it wrote) must also be AddOrMoveToEnd, or a default-Fifo call queued later can still run first.

Coalescing keys off DisplayInfo, which can be stale

AddOrMoveToEnd's de-dup cancels an older pending task sharing the same EffectiveId (CustomId ?? DisplayInfo). A DisplayInfo built from mutable state (e.g. element.ToString() → Name) gives two logically-identical requests different ids across a mutation, so they never coalesce. Also: AddOrRunIfTasked's "already in a task, run inline" fast path explicitly excludes AddOrMoveToEnd — it always goes through the real queue.

A same-tier task queued early can still surface last

GenerateElementCode on a screen with N derived screens synchronously enqueues one AddOrMoveToEnd task per derived screen the moment it runs - so any other AddOrMoveToEnd call made around the same time (e.g. a plugin's own error-refresh reacting to the same property change) ends up dequeued after all N of them, even though it was queued just as early. This is "tiers beat enqueue order" above, just easy to miss because the delay looks like your call ran late, not like a same-tier burst beat it. RefreshCommands.RefreshErrorsFor (RefreshCommands.cs) takes an optional executionPreference for exactly this: pass Fifo (or anything but AddOrMoveToEnd) from a reaction that must show up promptly, and - since AddOrRunIfTasked's inline fast path excludes only AddOrMoveToEnd - if you're already inside a task, it runs immediately instead of queueing at all. Conversely, a reaction that must wait until codegen has actually landed still wants AddOrMoveToEnd (see above).

The nested-task fast path checks TaskManager.Self, not the calling instance

AddOrRunIfTasked's IsInTask() gate is hardcoded to TaskManager.Self.SyncTaskThreadId, not this.SyncTaskThreadId — so a TaskManager.Self.AddAsync(...) call made from inside an already-running task's callback (any preference except AddOrMoveToEnd) runs inline via RunTask(...).Wait() instead of re-entering the priority queue, meaning its own TaskExecutionPreference argument is inert. In production this is safe because StartDoTaskManagerLoop wraps the dedicated task thread in Nito.AsyncEx's AsyncContext.Run, which pins every await continuation started within it back to that same thread — so IsInTask() still sees the same thread ID after any number of nested awaits. This can't be observed under GlueUnitTests: GlueTestBootstrap forces SynchronousMode = true before TaskManager.Self is ever constructed, which permanently fixes that one singleton instance's SyncTaskThreadId to whatever thread first touched it — no later toggle of TaskManager.SynchronousMode (e.g. in TaskManagerSynchronousModeTests) un-fixes it, so nested calls always look "in task" there regardless of what the real threaded model would do.