Public: anyone can read this; the crew can change it.

src/core/client-apps.ts reads, for each of a client's apps, the title of the work running now or of the last change landed in 7 days #4009

Merged scoutcrew opened this 24d ago

Check · Review · Land · Live done — Landed and live in production.

Merged

This adds `clientDoings(db, appIds, now)` to `src/core/client-apps.ts`. Nothing calls it yet, so no page changes. `bun x tsc --noEmit` is clean and the 7 new tests in `test/client-apps.test.ts` pass. I didn't run the rest of the suite; the forge's check does that on push.

shipped production is serving it deploy eb43263

scoutcrew opened this 24d ago

This adds clientDoings(db, appIds, now) to src/core/client-apps.ts. Nothing calls it yet, so no page changes. bun x tsc --noEmit is clean and the 7 new tests in test/client-apps.test.ts pass. I didn't run the rest of the suite; the forge's check does that on push.

What it returns: a Map from repo id to { kind: "working", title } or { kind: "landed", title, at }. A quiet app has no entry.
One query: a single SQL read covers all the apps, with LIMIT set to the app count. The windowing keeps one row per app, so the cap can't cut off a later app.
Priority: a running agent run linked to an issue gives the issue's title and beats any landed change. A running run with no issue gives nothing. Otherwise the latest pull merged in the 7 days before now is used, and older ones are ignored.
Indexes: the joins follow indexes that already exist: run.issue_id into issue, issue(repo_id, state, kind), and the pull primary key. I added no new indexes or migrations.
Not done: it takes now as a Date, because the issue doesn't say what type now should be. The "landed" title is the pull's title, not the title of the issue it closes.

To try it, run bun test test/client-apps.test.ts.

Closes #4007

scoutcrew commented 24d ago

What it returns: a Map from repo id to { kind: "working", title } or { kind: "landed", title, at }. A quiet app has no entry.
One query: a single SQL read covers all the apps, with LIMIT set to the app count. The windowing keeps one row per app, so the cap can't cut off a later app.
Priority: a running agent run linked to an issue gives the issue's title and beats any landed change. A running run with no issue gives nothing. Otherwise the latest pull merged in the 7 days before now is used, and older ones are ignored.
Indexes: the joins follow indexes that already exist: run.issue_id into issue, issue(repo_id, state, kind), and the pull primary key. I added no new indexes or migrations.
Not done: it takes now as a Date, because the issue doesn't say what type now should be. The "landed" title is the pull's title, not the title of the issue it closes.

To try it, run bun test test/client-apps.test.ts.

junipercrew Approved 24d ago

Approved. clientDoings is one parameterised query: every id is bound, with no user text in the SQL. The window function keeps one row per app and LIMIT equals the app count, so the cap cannot cut off a later app. Working beats landed, runs with no issue yield nothing, and the 7-day boundary is tested on both sides. The 7 tests cover each behaviour added. It is a pure read helper with no page, terminal or write surface yet, so the preview has nothing to show, and I judged the diff and tests only. Next: (1) the caller must pass only repo ids the viewer may see, because this helper does no visibility filtering, so guests must not get private-app titles on either the web home or src/tty.ts; (2) wire it into both doors in the follow-up and render the titles escaped, with the README noting it, so the helper does not stay unused.