## batch-core continued — the source-issue cluster Follow-on to #2780 (merged). Scope is still `packages/core` + `packages/dashboard/src`. ### The defect Five places asked the same question — *has this task landed?* — and all five compared against the literal `done`: | surface | consequence on a renamed board | |---|---| | GitHub source-issue commenter | never comments on or closes the source issue | | GitLab source-issue commenter | same | | GitLab `closedAt` backfill reconciler | finds nothing, reports a clean scan | | session-diff boundary | finished tasks diff against an already-merged branch | | tracking-comment transition | (already converted; left alone) | The commenters are the sharpest case: they returned **before reading a single setting**, so on a renamed board the feature looked *disabled* rather than broken — an operator checking `githubCommentOnDone` would see it enabled and still get nothing. The backfill is the quietest: `scanned: N, filled: 0` reads as "nothing to do", so the failure was indistinguishable from success. ### The fix One home: `packages/dashboard/src/task-lifecycle-lanes.ts`. Callers now only ask. Five copies of one question is exactly how the halves drift apart — the motivating incident is FN-6115 → FN-6118 → FN-6123, where the same affordance was fixed three times because it lived in two components. This also folds in the duplicate landed-lane helper I had left in `register-session-diff-routes.ts` in the previous PR, which was the sixth copy waiting to happen. Two helpers, and the difference is deliberate: - **`landedColumnsForTask`** — `complete ∪ archived`. Membership, since a board may declare more than one column carrying either role, and `columnsWithFlag(...)[0]` would silently ignore the second. - **`completeColumnsForTask`** — complete only. The GitLab backfill's own FNXC note records that archived tasks live in `archiveDb` and are *intentionally* excluded, so it must not widen to the archived role just because the shared helper offers it. Today it lists with `includeArchived: false` and would see no archived rows either way — but that is an incidental property of the query, not the contract. The test pins the difference so the two are not later "simplified" into one, which would change that caller's behaviour without touching it. Both treat an **empty** resolved set as *unexpressed*, not absent — the v1 hazard: `synthesizeDefaultColumns` upgrades a v1 graph with `traits: []` on every column, so reading empty as "no complete lane" would stop these surfaces firing on every pre-v2 project. The reconciler is two-stage on purpose: the cheap provider and `closedAt` tests run first and reject almost everything, so a workflow read only happens for real candidates, and it shares one IR cache across the scan — one read per distinct workflow rather than per task. ### Census `batch-core` scope **75 → 72**; repo total **338**. ### Verification - `pnpm --filter @fusion/dashboard exec tsc --noEmit -p tsconfig.json` → 0 errors - `pnpm lint` → 0 errors - commenter + reconciler suites → **63 passed**; helper suite → **5 passed** - **Mutation-verified:** making the helper ignore its resolved set fails 1 of 5. --- ## Round 2 — server.ts, chat.ts, and a correction **Census: 75 → 67** across this PR. ### The correction (see the review thread above) My first pass gated the source-issue commenters on `landedColumnsForTask` (`complete ∪ archived`), which **widened** the trigger — `to === "done"` never fired on archival, and the landed set does. Both commenters now use `completeColumnsForTask`, and the unused `hasTaskLanded` wrapper is gone. The ratchet for it is pinned on the **default** board, deliberately: a widening is visible exactly where the legacy names still apply, so no renamed-board fixture would catch it. ### `chat.ts` — three sites, and a pair that had to move together - **Chat verification** required `column === "in-progress"`, so on a renamed board every chat-driven verification was refused with a message naming a column the board does not have. - **The planner refinement pair.** Two separate guards decide this feature: `createSession` *registers* the tool only for a finished task, and the tool's own `execute()` *refuses* a non-finished source. Both compared `done`. Converting only one half would have offered the tool and then had it refuse itself — the half-converted-pair shape. The new test asserts **both** halves in one case (tool present *and* refinement created), and each half reverted independently fails it. Existing `chat-manager` coverage caught neither revert, which is why the case exists rather than relying on the suite that was already there. Complete-only again, not the landed set: an archived task is off the board and is not a refinement source. ### `server.ts` - **Planner-chat retention** — the archival cutoff was a literal, so on a renamed board task-planner chat sessions were retained forever; the rule this listener exists to enforce never fired. Resolved, and awaited inside the existing fire-and-forget chain rather than by making the listener `async` — `task:moved` has synchronous subscribers whose ordering is load-bearing elsewhere, and a chat-row delete is not the right place to introduce a microtask boundary into that emit. - **`isBadgeEligibleTask` — deliberately NOT converted, and marked as backlog.** On a renamed board it is genuinely wrong: an archived card stays badge-eligible, its snapshot is never evicted, and the cache grows for the daemon's lifetime — the exact memory leak the predicate was added to fix, back under a different column name. What blocks it is measured, not assumed: both callers are synchronous `task:updated` / `task:created` listeners whose next statement is documented as *"Update local cache immediately"*, so awaiting lets a second event for the same task interleave between the eligibility check and the cache write. I did **not** add an optional `archivedColumns` parameter, because nothing could fill it — the callers are the sync listeners. That is the inert-injection shape this PR's own review caught twice on #2780: the predicate would read as converted, its test would pass by injecting the value, and production would keep the literal. The unblocking change (a resolved-archived-lane cache on the badge-snapshot scope, keeping the predicate synchronous) is recorded at the site. ### Verification - `tsc --noEmit` → 0 errors; `pnpm lint` → 0 errors - `chat-manager` → 101 passed; commenter/reconciler/helper/badge suites → 55 passed - Mutation-verified per fix, including each half of the refinement pair separately <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Improved task lifecycle handling for renamed workflow lanes, including completed, archived, landed, and in-progress states. * Task lists now exclude completed tasks regardless of the completion lane’s name. * Chat verification and refinement actions now recognize configured workflow lanes. * GitHub and GitLab completion comments trigger only for genuinely completed tasks, not archived tasks. * Knowledge index refreshes and GitLab metadata updates now support custom completion lanes. * **Tests** * Added regression coverage for renamed completion lanes and archived-task behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
129 lines
5.9 KiB
TypeScript
129 lines
5.9 KiB
TypeScript
import type { ProjectSettings, Task, TaskStore } from "@fusion/core";
|
|
import { resolveGitLabClient, resolveGitLabTarget, resolveGitLabTargetFromItem, safeLogGitLabEntry } from "./gitlab-lifecycle.js";
|
|
import { completeColumnsForTask } from "./task-lifecycle-lanes.js";
|
|
import { getCliPackageVersion } from "./cli-package-version.js";
|
|
import { formatReleaseVersionLines } from "./fusion-release-version.js";
|
|
|
|
interface TaskMovedEvent {
|
|
task: Task;
|
|
/** Present on the real store event; GitLabTrackingCommentService no-ops when `from === to`. */
|
|
from?: string;
|
|
to: string;
|
|
}
|
|
|
|
/*
|
|
* FNXC:GitLabIssueComment 2026-07-15-11:20:
|
|
* Requirement: a task must never receive TWO done comments on the SAME GitLab item. GitLab imports
|
|
* always carry BOTH linkages — buildGitLabTaskProvenance() returns sourceIssue AND gitlabTracking.item
|
|
* for the same item — so with `gitlabCommentOnDone` on, EVERY imported task was double-commented
|
|
* (broader than the GitHub case, where adoption is conditional).
|
|
*
|
|
* Identity here is by construction, not by comparison: resolveGitLabTarget() prefers
|
|
* gitlabTracking.item over sourceIssue, so whenever the item resolves, THIS service's target IS the
|
|
* tracking service's target. Suppress this service then and let the tracking service post the richer
|
|
* comment. With no item, resolveGitLabTarget() falls back to sourceIssue and this service still posts
|
|
* — the imported-with-tracking-off case.
|
|
*
|
|
* Mirrors the tracking service's `from === to` no-op guard: on a same-column re-emit it stays silent,
|
|
* so suppressing here would drop the only comment.
|
|
*/
|
|
function trackingCommentCoversTarget(event: TaskMovedEvent): boolean {
|
|
if (event.from === event.to) {
|
|
return false;
|
|
}
|
|
const item = event.task.gitlabTracking?.item;
|
|
return Boolean(item && resolveGitLabTargetFromItem(item));
|
|
}
|
|
|
|
export const DEFAULT_GITLAB_COMMENT_TEMPLATE = "✅ Task {taskId} ({taskTitle}) has been completed and resolved.";
|
|
|
|
/*
|
|
* FNXC:GitLabIssueComment 2026-07-15-10:40:
|
|
* Mirrors the GitHub self-repo release lines (issue #1916) via the shared fusion-release-version
|
|
* helper, so the two cannot drift the way github-issue-comment.ts drifted from
|
|
* github-tracking-comments.ts.
|
|
*
|
|
* NOT redundant with GitLabTrackingCommentService: this service covers the `sourceIssue` IMPORT
|
|
* linkage (documented `gitlabCommentOnDone`; docs/settings-reference.md), while that one covers the
|
|
* `gitlabTracking.item` linkage. An issue imported with tracking off has sourceIssue and no
|
|
* tracking, so THIS is the only surface that comments. Do not delete it as a duplicate.
|
|
*/
|
|
export class GitLabIssueCommentService {
|
|
private readonly store: TaskStore;
|
|
private readonly getCurrentVersion: () => string;
|
|
private readonly onTaskMoved = (event: TaskMovedEvent): void => { void this.handleTaskMoved(event); };
|
|
private started = false;
|
|
|
|
constructor(store: TaskStore, getCurrentVersion?: () => string) {
|
|
this.store = store;
|
|
this.getCurrentVersion = getCurrentVersion ?? (() => getCliPackageVersion());
|
|
}
|
|
|
|
start(): void {
|
|
if (this.started) return;
|
|
this.started = true;
|
|
this.store.on("task:moved", this.onTaskMoved);
|
|
}
|
|
|
|
stop(): void {
|
|
if (!this.started) return;
|
|
this.started = false;
|
|
this.store.off("task:moved", this.onTaskMoved);
|
|
}
|
|
|
|
private async handleTaskMoved(event: TaskMovedEvent): Promise<void> {
|
|
/*
|
|
FNXC:WorkflowResolvedColumns 2026-07-30-04:40 (batch-core, corrected after #2783 review):
|
|
The GitLab twin of the GitHub commenter's completion check — same question, same literal, same
|
|
silent no-op on a renamed board. Provider is tested first because it is free; the lane resolution
|
|
is not.
|
|
|
|
COMPLETE ONLY, matching its twin: the landed set would widen the trigger to archival, which the
|
|
original `to === "done"` never fired on.
|
|
*/
|
|
if (event.task.sourceIssue?.provider !== "gitlab") return;
|
|
if (!(await completeColumnsForTask(this.store, event.task.id)).has(event.to)) return;
|
|
const settings = await this.store.getSettings() as Pick<ProjectSettings, "gitlabCommentOnDone" | "gitlabCommentTemplate">;
|
|
if (settings.gitlabCommentOnDone !== true) return;
|
|
|
|
const target = resolveGitLabTarget(event.task);
|
|
if (!target) {
|
|
await safeLogGitLabEntry(this.store, event.task.id, "Skipped GitLab source comment", "Linked GitLab source metadata is incomplete");
|
|
return;
|
|
}
|
|
|
|
if (trackingCommentCoversTarget(event)) {
|
|
await safeLogGitLabEntry(this.store, event.task.id, "Skipped GitLab source comment", `${target.label} is tracked; GitLab tracking comment covers it`);
|
|
return;
|
|
}
|
|
|
|
const template = settings.gitlabCommentTemplate || DEFAULT_GITLAB_COMMENT_TEMPLATE;
|
|
let body = template.replaceAll("{taskId}", event.task.id).replaceAll("{taskTitle}", event.task.title ?? "");
|
|
|
|
// Project PATH only — resolveGitLabTarget() prefers the numeric projectId, which never matches the slug.
|
|
const repository = event.task.gitlabTracking?.item?.projectPath ?? event.task.sourceIssue?.repository;
|
|
if (repository) {
|
|
const versionLines = formatReleaseVersionLines(repository, () => this.getCurrentVersion());
|
|
if (versionLines.length > 0) {
|
|
body += `\n\n${versionLines.join("\n")}`;
|
|
}
|
|
}
|
|
|
|
try {
|
|
const resolved = await resolveGitLabClient(this.store);
|
|
if (!resolved.ok) {
|
|
await safeLogGitLabEntry(this.store, event.task.id, "Skipped GitLab source comment", resolved.message);
|
|
return;
|
|
}
|
|
if (target.kind === "merge_request") {
|
|
await resolved.client.commentOnMergeRequest(target.project, target.iid, body);
|
|
} else {
|
|
await resolved.client.commentOnProjectIssue(target.project, target.iid, body);
|
|
}
|
|
await safeLogGitLabEntry(this.store, event.task.id, "Posted GitLab issue completion comment", target.label);
|
|
} catch (error) {
|
|
await safeLogGitLabEntry(this.store, event.task.id, "Failed to post GitLab issue comment", error instanceof Error ? error.message : String(error));
|
|
}
|
|
}
|
|
}
|