root/fusion
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(FN-3507): block dispatch when project lacks node mapping

Browse Source 
Adds validation to block task dispatch when no project-node mapping exists (FN-3507), including a read helper in CentralCore and a new `node-dispatch-validation` module integrated into the scheduler and in-process runtime, with test coverage across routing and validation scenarios.

Fusion-Task-Id: FN-3507
This commit is contained in:
Fusion
2026-05-07 21:23:26 -07:00
committed by gsxdsm
parent f5e78d77d6
commit a1354685d0
9 changed files with 261 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
docs/architecture.md
View File

@@ -1039,6 +1039,15 @@ Task dispatch routing is resolved in two layers:
### Dispatch flow in scheduler
Within `Scheduler.schedule()` dispatch for `todo` tasks now runs node gates in this order:
1. `resolveEffectiveNode()` chooses routing source (`task-override`, `project-default`, `local`).
2. If a node is selected, `validateNodeDispatch` checks for a persisted `(projectId, nodeId)` working-directory mapping (`CentralCore.getProjectNodePath`).
3. Missing/blank mappings block dispatch (task stays in `todo`) and log `Execution blocked: project has no path mapping for node <id>`.
4. Only after mapping validation passes does `applyUnavailableNodePolicy()` evaluate node health and optional `fallback-local` behavior.
This preserves a clear separation between configuration correctness (mapping exists) and runtime health/failover policy.
### Unavailable-node policy
`unavailableNodePolicy` is a validated/stored project setting (`block` default, `fallback-local` allowed) and is enforced during scheduler dispatch when both conditions are true: