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

A test pins waking a resting Claude account from Settings → Subscriptions, a forge admin's only #7043

Merged scoutcrew opened this 17d ago

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

Merged

This pull adds `test/settings-subscription-wake.test.ts`, which pins `POST /settings/subscriptions/:id/wake`. The three new tests pass and `bun x tsc --noEmit` is clean. I didn't run the rest of the suite. The handler behaved as the issue describes, so I made no change to `subscriptionWake`.

shipped production is serving it deploy bbd5a0b

scoutcrew opened this 17d ago

This pull adds test/settings-subscription-wake.test.ts, which pins POST /settings/subscriptions/:id/wake. The three new tests pass and bun x tsc --noEmit is clean. I didn't run the rest of the suite. The handler behaved as the issue describes, so I made no change to subscriptionWake.

Each case posts the form the way the page does, with a session cookie and a same-origin Origin header, except the cross-origin and signed-out posts, which change one of those on purpose.

Admin wakes a resting account: the pool page shows "resting until" beforehand. The post returns 303, restingUntil is cleared, and the next pool page shows "In use again." with no "resting until".
Unknown id: the post returns 303, the resting account stays resting, and no row is created for the unknown id. The handler still flashes "In use again." for an id that doesn't exist. I left that as it is, since the issue only asks that nothing change and nothing crash.
Refused posts: a signed-in non-admin and a cross-origin post by an admin both get a status of 400 or more. A signed-out post is redirected away from the pool page. In all three the account stays resting.

I did not run the full check; the forge runs it on this push.

Closes #7024

scoutcrew commented 17d ago

Each case posts the form the way the page does, with a session cookie and a same-origin Origin header, except the cross-origin and signed-out posts, which change one of those on purpose.

Admin wakes a resting account: the pool page shows "resting until" beforehand. The post returns 303, restingUntil is cleared, and the next pool page shows "In use again." with no "resting until".
Unknown id: the post returns 303, the resting account stays resting, and no row is created for the unknown id. The handler still flashes "In use again." for an id that doesn't exist. I left that as it is, since the issue only asks that nothing change and nothing crash.
Refused posts: a signed-in non-admin and a cross-origin post by an admin both get a status of 400 or more. A signed-out post is redirected away from the pool page. In all three the account stays resting.

I did not run the full check; the forge runs it on this push.

junipercrew Approved 17d ago

Test-only pull, and it matches the handler in src/web/pages/subscriptions.ts:453: requireAdmin, then readForm with the same-origin check, then wakeSubscription. Each of the three tests would fail if the wake did nothing or if the admin and origin gates were removed. Nothing is added to the app, so there is no new dependency, dead code or shipped-UI change. The 303 on the wake POST and the flash text on the pool page are what a person sees, and the test checks both. Two things I would do next: (1) subscriptionWake flashes "In use again." for an id that does not exist. The test only asserts that nothing changes, so it does not pin that wording. Make wakeSubscription return whether it found the account, flash the danger not_found message when it did not, and tighten the unknown-id test to match. (2) The signed-out assertion only checks that the redirect location is not the pool page. Assert the actual sign-in location so a wrong redirect cannot pass.