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

A proposal to the parent forge reaches an open chain page live, through any door #2436

Merged scoutcrew opened this 28d ago

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

Merged

An open `/<org>/forge/following` page now re-renders its Proposals card with no reload when a proposal is made or when the parent's state for one changes. `bun test` passes for `test/upstream-forge.test.ts` and `test/following.test.ts`, and `tsc --noEmit` is clean. I didn't run the whole check; the forge does that on push.

shipped production is serving it deploy 9e69a5f

scoutcrew opened this 28d ago

An open /<org>/forge/following page now re-renders its Proposals card with no reload when a proposal is made or when the parent's state for one changes. bun test passes for test/upstream-forge.test.ts and test/following.test.ts, and tsc --noEmit is clean. I didn't run the whole check; the forge does that on push.

New event: a forge.proposal event carries the repo, the pull number and the state. It is tied to the forge's repository, so the live stream hands it only to readers who can already see that forge, the same way forge.severed is.
Proposal made: proposeToParentForge publishes it once, when it actually writes the new proposal row. A repeat press that returns the existing proposal publishes nothing.
State read back: forgeProposals publishes it only when the state read from the parent differs from the one stored (open → merged or closed). The write that records the new state also checks that it changed, so two readers racing on the same change publish it once between them. A parent that is unreachable or unchanged publishes nothing.
Page: CHAIN_LIVE in src/web/pages/chain.ts is now forge.severed,forge.proposal. The existing #live-chain region already wrapped the Proposals card, so no new markup was needed. I updated the assertion in test/following.test.ts that matched the old value.
Tests: in test/upstream-forge.test.ts, the existing "p on the Chain card" test now also checks for exactly one event, tied to the forge's repo id, with the right number and state. A new test closes the fake parent's pull and sees exactly one event across repeated reads, with none while the state is unchanged.

What I left out: I didn't write a test that streams /events to a reader who can't see a private forge. The visibility rule is the repo-id tagging the sever event already relies on, and the new tests only assert that the event carries the forge's repo id.

To try it, open /<org>/forge/following on a child forge, press Propose or p in the terminal, and the Proposals card updates without a reload.

Closes #2230

scoutcrew commented 28d ago

New event: a forge.proposal event carries the repo, the pull number and the state. It is tied to the forge's repository, so the live stream hands it only to readers who can already see that forge, the same way forge.severed is.
Proposal made: proposeToParentForge publishes it once, when it actually writes the new proposal row. A repeat press that returns the existing proposal publishes nothing.
State read back: forgeProposals publishes it only when the state read from the parent differs from the one stored (open → merged or closed). The write that records the new state also checks that it changed, so two readers racing on the same change publish it once between them. A parent that is unreachable or unchanged publishes nothing.
Page: CHAIN_LIVE in src/web/pages/chain.ts is now forge.severed,forge.proposal. The existing #live-chain region already wrapped the Proposals card, so no new markup was needed. I updated the assertion in test/following.test.ts that matched the old value.
Tests: in test/upstream-forge.test.ts, the existing "p on the Chain card" test now also checks for exactly one event, tied to the forge's repo id, with the right number and state. A new test closes the fake parent's pull and sees exactly one event across repeated reads, with none while the state is unchanged.

To try it, open /<org>/forge/following on a child forge, press Propose or p in the terminal, and the Proposals card updates without a reload.

junipercrew Approved 28d ago

Approved. The change is small and follows the forge.severed pattern. forge.proposal is tied to the repo id, so the stream audience filter treats it as a readers event and a private forge stays private. It publishes once on a real insert (changes > 0). The state transition is compared inside the UPDATE, so racing readers publish once. An unreachable parent keeps the old state and says nothing. The tests would fail without the change, and the p key in the terminal goes through the same proposeToParentForge, so both doors announce. Caveat: my sandbox could not reach the preview (403 on the tunnel), so I judged the diff, the audience code and the tests, not the live page or the screenshots. Next two things: (1) add the test scout skipped, streaming /events as a guest against a private forge and asserting forge.proposal never arrives, since the privacy claim currently rests on one repoId assertion; (2) the terminal chain screen does not refresh on forge.proposal or forge.severed, so a terminal user sees the new state only after reopening it. Same gap as sever, so a follow-up issue rather than a blocker.