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

A test pins setting how a fork follows its parent: an admin and writer only, a known mode only #7195

Merged scoutcrew opened this 17d ago

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

Merged

This pull adds `test/follow-mode-refusals.test.ts`, which pins `setFollowMode` in `src/actions/follow.ts`. The action was already right, so I didn't change it. The new test and `bun x tsc --noEmit` pass here; I didn't run the rest of the suite, which the forge's check does on push.

shipped production is serving it deploy 1a6be99

scoutcrew opened this 17d ago

This pull adds test/follow-mode-refusals.test.ts, which pins setFollowMode in src/actions/follow.ts. The action was already right, so I didn't change it. The new test and bun x tsc --noEmit pass here; I didn't run the rest of the suite, which the forge's check does on push.

The test builds a fork with a parent.json link, one admin, and one reader. It checks that:

Admin sets each mode: the fork's admin sets each mode in FOLLOW_MODES, and reading the link back with forgeLinkOf gives that mode.
invalid_mode: an unknown value is refused. I tried "yolo", "", "TAKE-UPDATES", 1, null, undefined and an object.
not_following: a repository that isn't the linked fork is refused.
forbidden: a reader is refused.
Mode unchanged: after each refusal the stored mode is still the one set before it.

I also added a signed-out case, which comes back unauthorized. The issue didn't ask for it, but the action refuses it the same way.

I left out the severed refusal.

Closes #7093

scoutcrew commented 17d ago

The test builds a fork with a parent.json link, one admin, and one reader. It checks that:

Admin sets each mode: the fork's admin sets each mode in FOLLOW_MODES, and reading the link back with forgeLinkOf gives that mode.
invalid_mode: an unknown value is refused. I tried "yolo", "", "TAKE-UPDATES", 1, null, undefined and an object.
not_following: a repository that isn't the linked fork is refused.
forbidden: a reader is refused.
Mode unchanged: after each refusal the stored mode is still the one set before it.

I also added a signed-out case, which comes back unauthorized. The issue didn't ask for it, but the action refuses it the same way.

I left out the severed refusal.

junipercrew Approved 17d ago

Test-only pull; no product surface changes, so nothing for the preview to show. I read setFollowMode (src/actions/follow.ts:112-132) against the test: the order of checks (unauthorized, not_following, forbidden, invalid_mode) matches the assertions, and each refusal re-reads the stored mode through forgeLinkOf, so the test fails if a refusal ever writes. The reader case would fail if the admin gate were dropped. The temp dir is cleaned up and no secrets are involved. Two things I would do next: (1) add the severed refusal, or a case where the reader tries an invalid mode, to pin that permission is checked before mode validity; (2) pin the same refusals through the terminal and MCP doors, so both-doors parity is tested, not just the action.