fix(server): report plan-issue label failures to the user #279

Merged

lucas merged 1 commit from agent/issue-271-plan-issue-label-reports into main

2026-11-13 15:19:03 +01:00

omp-deck commented

2026-11-13 14:49:55 +01:00

Collaborator

Starting a Plan issue session or publishing its plan applied implementation.planning_label / planned_label silently: every failure mode (config file unreadable, the whole file rejected over an unrelated block, an unknown/ambiguous label, a failed label write) ended in a log.warn on the server's stdout and nothing else, so the label simply did not appear and no reason was recoverable from outside.

What changed:

markIssue returns the failure reason instead of swallowing it; it still never throws and never fails planning or publishing.
A new reportProblem helper raises an error-level notification (source: forgejo-plan-issue) through the existing notificationService, so it reaches the toast and the Settings notification log. error keeps the toast up until dismissed, which matters because the user is navigating into the new session at that moment.
Both config failures in implementationLabels (non-404 read failure, parse failure, thrown error) and both label moments (planning label at session start, planned label at publish) now report. The legitimate quiet paths stay quiet: no config file at all, or no label configured.
PublishOutcome's ok-variant gained an optional labelProblem, which plan-mode-bridge appends to the published text, so the agent can say in its reply that the issue was published without its planned label. Without a problem the message is byte-identical to before.

Verification:

bun test apps/server/src/forgejo/plan-issue.test.ts apps/server/src/bridge/plan-mode-bridge.test.ts — 51 pass, including new cases for: unknown planning label at start, invalid repo config at start, nothing configured (asserts no notification), publish with an unknown planned label (ok: true + labelProblem + one notification), publish success (no labelProblem, no notification), and the two bridge message shapes.
bun test apps/server/src/forgejo/dispatcher.test.ts — 176 pass, unchanged.
bun run typecheck — clean across all packages (this is what proves every PublishOutcome / publishedText caller was migrated).

Not verified here: the end-to-end toast in a running deck, which needs a browser.

Closes: #271

Starting a **Plan issue** session or publishing its plan applied `implementation.planning_label` / `planned_label` silently: every failure mode (config file unreadable, the whole file rejected over an unrelated block, an unknown/ambiguous label, a failed label write) ended in a `log.warn` on the server's stdout and nothing else, so the label simply did not appear and no reason was recoverable from outside. What changed: - `markIssue` returns the failure reason instead of swallowing it; it still never throws and never fails planning or publishing. - A new `reportProblem` helper raises an `error`-level notification (`source: forgejo-plan-issue`) through the existing `notificationService`, so it reaches the toast and the Settings notification log. `error` keeps the toast up until dismissed, which matters because the user is navigating into the new session at that moment. - Both config failures in `implementationLabels` (non-404 read failure, parse failure, thrown error) and both label moments (planning label at session start, planned label at publish) now report. The legitimate quiet paths stay quiet: no config file at all, or no label configured. - `PublishOutcome`'s ok-variant gained an optional `labelProblem`, which `plan-mode-bridge` appends to the published text, so the agent can say in its reply that the issue was published without its planned label. Without a problem the message is byte-identical to before. Verification: - `bun test apps/server/src/forgejo/plan-issue.test.ts apps/server/src/bridge/plan-mode-bridge.test.ts` — 51 pass, including new cases for: unknown planning label at start, invalid repo config at start, nothing configured (asserts *no* notification), publish with an unknown planned label (`ok: true` + `labelProblem` + one notification), publish success (no `labelProblem`, no notification), and the two bridge message shapes. - `bun test apps/server/src/forgejo/dispatcher.test.ts` — 176 pass, unchanged. - `bun run typecheck` — clean across all packages (this is what proves every `PublishOutcome` / `publishedText` caller was migrated). Not verified here: the end-to-end toast in a running deck, which needs a browser. Closes: #271

omp-deck added 1 commit

2026-11-13 14:49:56 +01:00

fix(server): report plan-issue label failures to the user 6088b09538

Applying the plan-issue lifecycle labels failed silently: an unreadable
or rejected `.omp/forgejo.yaml`, an unknown or ambiguous label and a
failed label write all ended in a `log.warn` on the server's stdout,
leaving no trace in the UI, so the labels simply never appeared and
nobody could tell why.

Each of those failures now raises an error notification naming the
repository, the issue and the reason, at session start and at publish
time. A publish-time failure is additionally carried into the approval
message the agent receives, so its reply can mention that the issue was
published without its planned label. Nothing becomes fatal: the planning
session still starts and the issue is still published. A repository with
no config file, or one that configures no labels, stays silent.

Co-Authored-By: Claude Opus 5 via omp-deck