2d42476dac
The duplicate and refine task routes returned without invoking createTrackingIssueForTask, depending on TaskStore's internal task-created hook to do it. That works in production with a real TaskStore but leaves no path through mocked test stores — which is why routes-tasks-ops's duplicate/refine tests expecting createIssue calls were failing. Call createTrackingIssueForTask explicitly after duplicateTask and refineTask, in a best-effort try/catch so a tracking failure can't block the response. Mirrors the existing PATCH /tasks/:id flow. Also wire registerGithubTrackingHook with a test logger in routes-planning-tracking.test.ts and have the mock store fire the hook after createTask so the planning create-task flow's expectations land. Fix the two PATCH tests in routes-tasks-ops that mocked getTask to already return a linked issue — using mockResolvedValueOnce for the pre-creation state and mockResolvedValue for the post-creation state so createTrackingIssueForTask sees the unlinked task first. Fixes 9 failing tests across routes-tasks-ops.test.ts (6) and routes-planning-tracking.test.ts (3). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
500 B
500 B
@runfusion/fusion
| @runfusion/fusion |
|---|
| patch |
Fire GitHub tracking-issue creation for duplicated and refined tasks. Previously the duplicate/refine routes returned without calling createTrackingIssueForTask, relying on TaskStore's hook — but mocked stores in tests (and certain race conditions) could bypass the hook, leaving the new task with no linked tracking issue. The routes now invoke tracking explicitly as a best-effort step after creation, matching the PATCH-with-githubTracking path's behavior.