bug: a disabled repository with a schedule row still names a next run on the page and the dashboard #723

Written-by: Fledge Platform Product

Expected vs actual

Actual — two surfaces decide a paused repository's next run without asking whether it is enabled.

• Repository page: const nextRunText = scheduledNext === undefined ? nextRunLine(nextRunState, t) : plannedNextLine(scheduledNext, t) (src/views/pages.ts:1259). The disabled answer exists only in nextRunLine (:730, 仓库已停用，自动运行不会开始) and is therefore reachable only when there is no schedule row. The route attaches scheduledNext whenever a row exists, with no enabled check (src/app.ts:1884–:1889), so a disabled repository with a row prints the planner's instant, tagged data-next-source="schedule" (src/views/pages.ts:1312).
• Dashboard: nextScheduledRun builds its candidate list with repos.filter((repo) => repo.auto_iterate === 1) (src/views/pages.ts:756) — enabled is not consulted — and the row branch returns plannedNextLine with runnable: scheduled.kind !== 'unreadable' && scheduled.at !== null (:768–:770). A paused repository is therefore runnable and can be chosen as the earliest, then named in 下次自动运行：<repo> · <instant> (:794–:797). Its input allRepos comes from store.listRepos (src/app.ts:1205, src/db.ts:4122–:4124), which has no enabled filter.

Worker truth. The scheduler only ever considers enabled repositories: listAutoRepos() is WHERE enabled = 1 AND auto_iterate = 1 (src/db.ts:4164–:4165), consumed by the auto-run loops (src/jobs/service.ts:594, :3238), and a manual start on a disabled repository is refused with REPO_DISABLED (src/jobs/service.ts:765). Both surfaces therefore name a run the worker will never do.

How the state is reached. Two routes, both live:

• /repos/:id/disable writes { enabled: 0, auto_iterate: 0 } and leaves the schedule row in place (src/app.ts:3310) — enough for the page case.
• The settings form writes auto_iterate and enabled from two independent checkboxes (src/app.ts:3245–:3246), so enabled = 0, auto_iterate = 1 is reachable — enough for the dashboard case, where a paused repository can shadow an enabled one.

Expected. enabled = 0 decides the next-run answer on every surface, exactly as the no-row branch already does. A paused repository says it is paused, and the dashboard never names a paused repository while an enabled one has a next run.

Environment. Fledge self-hosted, main at ffa010ed3bd1036ea07c706c31b28f1e7a0496e5, Node 22, /repos/:id and /dashboard.

Minimal reproduction

1. On a test instance (never the live database), create a repository with auto-iteration on and save a schedule row: cron 0 9 * * 1-5, Asia/Shanghai, via store.saveSchedule (src/db.ts:4186).
2. Press 停用 (or save settings with Enabled unchecked).
3. /repos/:id prints 下次约 <instant> from the row (data-next-source="schedule") instead of 仓库已停用，自动运行不会开始. The worker will never run it.
4. Dashboard variant: save settings with Enabled unchecked and auto-iterate still checked (src/app.ts:3245–:3246). With a second, enabled repository whose cron is later, /dashboard's all-clear card can name the paused repository as 下次自动运行, shadowing the enabled one.

Proposed red test

test/nextScheduledRun.test.ts already owns this surface, and the two halves exist separately today: :144 "a disabled repository says so on both surfaces instead of a happy time" (no schedule row) and :173 "the dashboard answers with the schedule row, not the interval, when one exists" (enabled repository). Add:

1. Page, disabled + row. The :173 fixture plus store.updateRepo(repo.id, { enabled: 0 }): assert repoLine(page) is the disabled sentence and not a formatted instant. Today it prints the planner instant → red.
2. Dashboard, a paused repository cannot win. Two repositories — paused (enabled = 0, auto_iterate = 1, hourly cron) and enabled (daily cron): assert the card names the enabled one. Today the paused repository is runnable and earliest → red.
3. Dashboard, no enabled candidate. Only the paused repository: assert the card says 自动运行暂停 with the disabled sentence and no instant.

The existing :135 and :173 cases must keep passing unchanged: an enabled repository with a row still prints the planner's instant.

Shape

One condition, two branches: enabled answers before the row does. Both surfaces defer to the existing disabled state of nextRunLine (src/views/pages.ts:730), so no member is added to NextRunState (src/lib/nextRun.ts:9) and the view keeps one wording.

If #713's digest helper is already on main, the gate belongs in that helper so the email follows in the same PR — and this PR then flips #713's case 2b assertion in test/jobs.test.ts, because the answer it aligned to (a paused repository naming an instant) is the one this card corrects.

Acceptance

1. enabled = 0 prints the disabled sentence on the repository page, with or without a schedule row.
2. The dashboard never names a paused repository as the next automatic run while an enabled repository has one.
3. With only paused repositories, the card says automatic runs are paused and names no instant.
4. An enabled repository with a schedule row still prints the planner's instant on both surfaces — no regression of feat: show one next-run time on the dashboard and the repository page, computed by one function #564/bug: the dashboard's next-run card ignores a repository schedule and disagrees with the schedule console #688.
5. The rendered line still carries data-next-source, and its value stays honest about which rule answered.
6. docs/architecture.md:107–:113 names enabled as part of the one next-run rule.
7. If the bug: the daily digest must print the repository's scheduled next run, not the interval answer #713 helper is on main, the digest gives the same answer and bug: the daily digest must print the repository's scheduled next run, not the interval answer #713's case 2b is flipped in this PR.
8. One changelog fragment changelog.d/<issue>.fixed.md; npm run check green; computed tier T2 (src/views/pages.ts; T3 only if the slice also reaches src/db.ts or src/jobs/).

Non-goals

• No change to what disabling does to queued work (cancelRepoJobs, src/app.ts:3311) or to listRepos's filtering for the digest's job history.
• No scheduler, misfire or timezone semantics — that is feat: make scheduled runs first-class occurrences with timezone, misfire and layered budgets #544.
• No new NextRunState member, and no move of the view helpers into src/lib/ beyond the bug: the daily digest must print the repository's scheduled next run, not the interval answer #713 helper.
• No schedule-row deletion on disable: a disabled repository keeps its row.

Relations

• bug: the daily digest must print the repository's scheduled next run, not the interval answer #713 (daily digest) aligned the email to the page for exactly this fixture; this card corrects the page. They must land bug: the daily digest must print the repository's scheduled next run, not the interval answer #713 first, so no card has to assert an answer that is about to change, and this PR then flips bug: the daily digest must print the repository's scheduled next run, not the interval answer #713's case 2b.
• feat: show one next-run time on the dashboard and the repository page, computed by one function #564, bug: the dashboard's next-run card ignores a repository schedule and disagrees with the schedule console #688 and feat: give a repository schedule a console that reads the planner #673 built the one-next-run rule and the schedule console; feat: make scheduled runs first-class occurrences with timezone, misfire and layered budgets #544 owns planner semantics; feat: add a platform-wide emergency stop and resume #283 is the platform-wide stop.

Dedupe

No open or closed issue reports it — searches for disabled, 仓库已停用 and "next run" return #713 and the rule cards (#564, #688, #673, #544) only, and none of them mentions a paused repository being named. No open PR's patch contains nextScheduledRun, plannedNextLine, scheduledNext, nextRunLine or data-next-run: #717, #699, #686, #609 and #531 touch src/views/pages.ts, but none of those symbols. The only recent commit touching that file is #687/#696 (admin sections, release-chain empty state).

Priority

normal — the console promises a run for a repository the worker skips; it can mislead an operator into thinking a paused repository will still run, but nothing is corrupted and the worker itself is correct.

Every file:line above was read at main ffa010ed3bd1036ea07c706c31b28f1e7a0496e5 (GitHub API and the tip tree, this turn).