The dashboard task-create route now uses the distributed task ID allocator (FN-3450). On projects whose tasks had been allocated through the legacy config.nextId counter, the allocator's `ensureStateRow` was seeding a fresh prefix at sequence 1, so new tasks restarted at FN-001 even when FN-3700 already existed. ensureStateRow now seeds past: - the legacy config.nextId counter (when configured taskPrefix matches), and - one past the highest numeric suffix on any existing tasks/archivedTasks row for the prefix. A regression test seeds FN-3700 in a fresh DB and asserts the next reservation returns FN-3701, not FN-001. Plugin dashboard view contracts are now exposed via a slim type-only module (`@fusion/dashboard/app/plugins/types`). External plugin tsc builds previously imported `pluginViewRegistry`, transitively pulling in dashboard runtime sources (React components, CSS, lucide-react). The dependency-graph plugin's import + path mapping is updated to use the new module. Schema housekeeping: drop unused scaffolding tables left over from an earlier migration via a new idempotent migration (v67). Fresh DBs see no change; existing DBs that ran the older migration get the orphan tables dropped on next init. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
774 B
774 B
@runfusion/fusion
| @runfusion/fusion |
|---|
| patch |
Fix task ID counter resetting to 001 on first mesh-routed task creation.
When the dashboard's task-create route was migrated to the distributed task ID allocator, projects whose tasks had been allocated through the legacy counter (e.g. FN-3700) saw new tasks restart at FN-001, colliding with historical IDs. The allocator now seeds its sequence past any existing task for the prefix (live or archived) and past the legacy counter, so new task IDs always continue forward.
Internal: extracted a slim type-only module for plugin dashboard view contracts so external plugin builds no longer pull in dashboard runtime sources, and dropped unused scaffolding tables (added by a previous schema migration) via an idempotent migration.