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

feat(FN-4044): restore github tracking patch persistence

Browse Source 
Restored GitHub tracking patch persistence in the core store with matching test coverage in the task detail and routes tasks ops suites, plus documentation for the repaired flow.

Fusion-Task-Id: FN-4044
This commit is contained in:
Fusion
2026-05-11 17:50:30 -07:00
committed by gsxdsm
parent 55bcf045eb
commit 1d6c85e900
6 changed files with 100 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
docs/task-management.md
View File

@@ -396,7 +396,7 @@ Manual/non-auto-merge behavior:
GitHub tracking issues are optional issues Fusion can create from Fusion tasks. They are **not** the same as imported source issues (`issueInfo` / `sourceIssue`): imported issues represent an existing GitHub issue that created the task, while tracking issues are new GitHub issues opened to track a Fusion task.
When task creation runs with tracking enabled, Fusion attempts issue creation during task creation flows (including quick create, planning output, automation `create-task` workflow steps, and subtask creation paths that create tasks). Fusion also retries issue creation on existing-task PATCH updates whenever the resulting task is **enabled and still unlinked** (including non-`githubTracking` edits), so previously skipped/unlinked tasks can recover later without a dedicated migration. Creation is best-effort and non-blocking: task updates and task creation still succeed even if repo resolution fails or GitHub calls fail.
When task creation runs with tracking enabled, Fusion attempts issue creation during task creation flows (including quick create, planning output, automation `create-task` workflow steps, and subtask creation paths that create tasks). For existing tasks, PATCH first persists any `githubTracking` mutation (enable/disable, repo override, or unlink), then evaluates whether the updated task is **enabled and still unlinked** and should trigger best-effort issue creation (including non-`githubTracking` edits). This keeps retry/create behavior consistent from Task Detail instead of relying on stale pre-patch state. Creation is best-effort and non-blocking: task updates and task creation still succeed even if repo resolution fails or GitHub calls fail.
Tracking behavior is controlled per task: