Successful yazar promote leaves divan roster and backlog stale

[usirin]

Verified at origin/main (5777b03): every claim below was re-read in source by triage — the gap is live at main, not superseded.

A moderator promotes a çaylak from the divan; the server commits correctly and atomically. Pasaport.promoteToYazar (apps/web/worker/features/pasaport/Pasaport.ts) runs one D1 batch whose first statement is the guarded tier flip (the tier = 'çaylak' guard makes a repeat call return promoted: false) followed by sandbox sweeps over the definition/post/comment tables. The reviewer's screen never learns:

• ReviewerActions.onPromote (apps/web/src/components/divan/CaylakDetail.tsx) awaits fate.mutations.user.promote(...), maps the outcome to a status string, and touches no read state — neither divan.roster nor the open divan.backlog.
• Both lists are plain one-shot reads: DivanRoster.tsx issues useRequest for the gated divan.roster root, CaylakDetail.tsx for divan.backlog. The divan has no /fate/live topic by design — apps/web/worker/features/divan/queries.ts says so itself: "No flag, no /fate/live topic: a plain one-shot query."
• The shared post-promote publish publishPromotion (apps/web/worker/features/pasaport/promote-live.ts) invalidates pano feed/thread/post/comment topics, sozluk definition topics, and the user entity only — nothing repairs either divan connection.

So the promoted person stays visible in the roster, their items stay pending, and a second press reports "kullanıcı zaten yazar." against stale state — reproduced on production today. Server truth is consistent (a fresh session shows the account gone from the roster), so this is purely client-side staleness. Triage note: the profile-page path has the same shape — PromotionActions.onPromote (apps/web/src/components/profile/PromotionActions.tsx) also sets only a message, and UserProfilePage.tsx reads the profile through cached useRequest rather than a live view — so its displayed çaylak/yazar status can go stale the same way.

Triage note: verified against react-fate 1.3.1 typings — useRequest returns a plain root map and its options carry only a fetch mode; there is no refetch handle. The original filer's guess stands: refreshing two private roots after a mutation may need a small fate-side expire/refetch primitive, or the handler can drive a fresh request itself. The mechanism is builder latitude; the observable outcome below is the contract.

Why this is standalone work

Searched the board for an owner of the post-promote client-refresh surface ("divan live subscription refetch stale cache after mutation", "promote yazar UI refresh moderator review") — no open issue or epic matches. Nearest neighbours do not own it: #1856 (moderation live pressure / divan surge badge) is an optional live-topic enhancement, not this staleness bug; #1206 (promotion feature) and #1841 (profile-button visibility) are closed. Minted standalone.

What done looks like

• After a successful promote from the divan reviewer actions, the promoted çaylak disappears from the rendered roster and their pending items disappear from the rendered backlog without a page reload.
• A second press after a visible success no longer reports "kullanıcı zaten yazar." for an entry stale state kept on screen.
• The profile-page promote handler receives the same post-success refresh treatment.
• Denied and errored attempts leave the current rendering untouched.
• New coverage pins the refresh behavior for both call sites; existing suites stay green.

Acceptance criteria

• A successful user.promote issued from ReviewerActions.onPromote refreshes both divan.roster and the open author's divan.backlog, so the promoted account and its pending items leave the screen without a full page reload.
• With the fix, pressing promote a second time cannot report "kullanıcı zaten yazar." while a stale roster/backlog entry for that user is still rendered.
• The profile-page promote path (apps/web/src/components/profile/PromotionActions.tsx) applies an equivalent post-success refresh mirroring the divan handler.
• Promote attempts ending in UNAUTHORIZED, FORBIDDEN, or a transport error change neither list's rendered contents.
• Unit tests cover the post-success refresh behavior for both call sites, and the existing divan/profile suites pass unchanged.

---

Original report (verbatim)

Summary

Promoting a çaylak from the divan commits correctly (tier flip + sandbox sweep in one atomic batch), but the reviewer's screen keeps showing the promoted person in divan.roster and their items in divan.backlog until the fate cache is rebuilt. The second press of "yazar yap" then reports "kullanıcı zaten yazar." against a list that should no longer contain them. Reproduced on production today.

What I was doing

Reviewing a çaylak on phoenix.kamp.us/divan as a moderator: pressed the promote button, got the success toast, then re-checked the roster after a page refresh.

What I observed

• The mutation response is correct: user.promote returns {promoted: true} and the D1 batch (buildPromotionStatements) flips user.tier AND clears sandboxed_at on all three content tables atomically.
• After the toast, the roster row and backlog item remain visible. Nothing in the client refetches either list: onPromote in CaylakDetail.tsx calls fate.mutations.user.promote(...) and only sets a status message.
• These lists are not live-subscribed (plain useRequest + useListView, no /fate/live topic for divan roots), and publishPromotion publishes invalidations for pano/sozluk topics plus the user entity — nothing repairs the divan connections.
• Verified server truth separately: a fresh logged-in session loading /divan shows the promoted account gone from the roster, so the stored state is consistent — this is purely client-side staleness.

Why it matters

A moderator who promotes one person sees a stale queue and reasonably presses promote again; the confusing "zaten yazar" message erodes trust in the review loop. Might also mask real regressions: a mod cannot tell "stale UI" from "promotion failed".

Pointers

• apps/web/src/components/divan/CaylakDetail.tsx — ReviewerActions.onPromote (no refetch after success)
• apps/web/src/components/divan/DivanRoster.tsx — roster read via useRequest({"divan.roster": ...})
• apps/web/worker/features/divan/lists.ts — gated list resolvers, no live topic
• apps/web/worker/features/pasaport/promote-live.ts — post-promote publish covers pano/sozluk/user only
• Same pattern likely in the profile-page promote action (UserProfilePage PromotionActions, Profile 'yazarlığa yükselt' button appears on own profile, then denies #1841)

Suggested next step (non-binding)

After a successful user.promote, refetch/expire the two private roots (divan.roster, and the open divan.backlog) in the same handler; mirror it in the profile-page promote path. A guess: fate's request cache may need an explicit expire/refetch primitive since useRequest exposes no refetch handle.

---

_{Filed by an agent · session 01a02c89-7810-7c22-8280-3c8a1feb8191 · branch umut/m50-diataxis-active · 2026-08-23T06:25:17Z}

[usirin]

[usirin]

Built PR #7040 on build/7036-promote-refresh-9841b5f9.

What was done: both promote call sites (divan ReviewerActions.onPromote and the profile-page PromotionActions) now drive one network-only re-pull of exactly what their screens render, after a settled tier answer (flip or already-yazar). The request shapes live in shared builders (divanReads.ts, profileReads.ts) that the mounted reads use too, so the refresh lands on the same cache keys by construction. Denials and transport errors refresh nothing.

Where to look first:

1. divanGating.ts promoteRefreshWarranted — the outcome→refresh policy both handlers share.
2. CaylakDetail.promote-refresh.test.tsx — pins mounted-read shape == builder shape, one combined network-only refresh per settled answer, nothing fired on denial/error.
3. The Deviations bullet in the PR body — refreshing on the already-yazar answer is the deliberate interpretation serving criterion 2.

Residual notes for review:

• A failed refresh is swallowed by design (promotion already succeeded; overwriting its message with an error would lie) — lists then stay stale exactly as before this fix.
• The divan topbar pending-count badge (divan.pendingCount) is NOT refreshed by the handler — outside this issue's criteria; it self-heals on navigation.
• fate's store/list-key mechanics (network-only re-request replacing rendered list state in place) were verified against react-fate 1.3.1 / @nkzw/fate installed source, not intuition; cited in the PR body.

[usirin]

Intent

Drive lane 7036 to terminal: the divan promote staleness fix is landed as PR #7040 (builder done, code review PASS); what remains is the review:ui gate, then ship.

Established

• Lane 7036 fold reads review:ui. Event log: ISSUE.WIP, ISSUE.DONE, ISSUE.PASS (PASS proven off PR fix: Successful yazar promote leaves divan roster and backlog stale #7040 and recorded by the driver after the builder shell timed out post-push; its terminal never landed itself).
• Code-review PASS is bound at PR head f16f726 (comment 5387907956), CI green at that head, all five issue acceptance criteria graded PASS by the reviewer shell.
• Lane machines were migrated to the committed template (lane migrate: 193 migrated, review:ui arm now present on this lane). 8 unsafe lanes were skipped and need a human call, not this lane's work: 5991, 6005, 6037, 6100, 6226, 6374, 6462, 6759.
• The lane claim held by the packing session is being released right after this pack lands; the successor claims the lane fresh with lane claim 7036.
• Both shells this session spawned timed out at the 30m runner cap AFTER finishing their board-visible work; this session ran on a free preview model, which is the likely flakiness source. Prefer a stronger model for the successor operator session.

Next act

Claim the lane (lane claim 7036), run lane brief 7036 with task issue (it routes review:ui to the ui-reviewer shell), spawn that shell with isolation worktree and the brief verbatim. On PASS, record and route to ship; on FAIL the machine spends a repair round. At the terminal fold, post the lane transcript on this issue and release the claim. Afterwards, restore the primary checkout stash entry that parks an untracked reports html file (stashed only to get a clean tree for worktree isolation).

Unsure

• The fold reads retries 2 of 2 spent, yet the event log holds no FAIL event (WIP, DONE, PASS only). I did not resolve why the budget reads exhausted. Inspect the lane document and events before dispatching, because a ui-review FAIL with zero budget may park frozen and need a founder-cleared round.
• Whether review:ui will PASS: the diff touches React components but is behavioral (refetch after mutation); the class routing is the machine's derivation, not judged by me.

Ground state — proven

{"issue":7036,"repo":"kamp-us/phoenix","capturedAt":"2026-08-23T19:35:35Z","git":{"branch":"main","head":"f73bc9c64c0153762eabf1c215fc15687b7abc94","upstream":"origin/main","reachable":"pushed","aheadBy":0,"behindBy":0,"base":{"branch":"main","head":"f73bc9c64c0153762eabf1c215fc15687b7abc94"},"tree":{"state":"clean","trackedModified":0,"untracked":0}},"board":{"issue":{"state":"open","labels":["p0","ready-for:agent","status:triaged","type:bug"]},"pull":null},"groundDigest":"29e3191da681"}

[usirin]