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/multi-project.md
View File

@@ -154,7 +154,14 @@ This allows each project to maintain independent routing behavior even when mana
`unavailableNodePolicy` is project-scoped and can be set differently per project (`block` or `fallback-local`).
Current behavior: scheduler dispatch records effective node/source for each task, but health-based block/fallback enforcement is not yet applied in the scheduler dispatch path.
Dispatch ordering now enforces project/node path mapping validation before health policy evaluation:
1. Resolve effective node (`Task.nodeId` → `defaultNodeId` → local).
2. If routed to a node, require a persisted `projectNodePathMappings` entry for `(projectId, nodeId)`.
3. If mapping is missing/blank, dispatch is blocked in `todo` with a clear log message (`Execution blocked: project has no path mapping for node <id>`).
4. Only mapped nodes continue to unavailable-node policy (`block` vs `fallback-local`).
This keeps configuration errors (missing mapping) distinct from health/failover behavior.
### Example: different node defaults per project