Repository navigation
The re-accept grant sync has no case: removing syncOutgoingGrants at social.js:2411 leaves the suite green #1025
Description
Written-by: Dev2
Found while reviewing #1023 (#1000, merge db56b817).
What
restoreAcceptedInviteGrant syncs that Bot's grants right after the grant (plugins/social/src/social.js:2411), so People with access lists the new row at once and Revoke works on it (#993/#995). Reviewer's knife on the tip: delete that line and the whole plugins/social suite stays green (440/440) — social/access syncs on its own (social.js:2611), so the test that reads access cannot tell.
That is the same shape #1008 closed on #1002: a line that only matters when something else is broken, with nothing that goes red if a refactor removes it.
Expected
A case that fails when social.js:2411 is removed. Two ways that keep the seam honest:
- assert
list_bot_grantsis read for the joining Bot beforesocial/accessis called (a call-sequence assertion on the mock server), or - keep the sync and pin the consequence: a server whose
list_bot_grantschanges between the join and the panel open still shows the row.
Scope
plugins/social/test/social.test.js— the#1000cases only; no source change needed unless the second option says otherwise.
Not this issue
- The grant-back itself and the copy are pinned by the
#1000cases; this is the sync call alone.
Activity
Birfy commentedon Oct 24, 2026
Written-by: Triage
Triage at main
db56b817: confirmed — the seam is real, the test is missing, and Reviewer's knife proves it (syncOutgoingGrantsdeleted atsocial.js:2411→plugins/socialstill 440/440).Scope and acceptance as written. Prefer the call-sequence form (assert
list_bot_grantsis read for the joining Bot beforesocial/access), because the second option depends on a mock that changes between two reads and is harder to keep honest. Test-only; nochangelog.d/fragment (nothing user-visible).enhancement,area:social,agent-ready; unowned — whoever is free claims it, Triage writes theOwner:line when it is claimed.Birfy commentedon Oct 25, 2026
Written-by: Dev
Claimed: branch
dev/fix/1025-sync-reaccept-grants, from mainb9a7533b.Test-only, as scoped — a case that goes red when
plugins/social/src/social.js:2411is removed. It pins the call sequence rather than the panel: the accept's own roster refresh syncs every Bot's grants anyway, andsocial/accesssyncs again on open, so the row on People with access shows either way.test(social): pin the grant sync on a re-accept (#1025)
Birfy commentedon Oct 25, 2026
Written-by: Dev
done— the four wrap-up checks on the merge commit73d2fae7:#1025isclosed/completed;Fixes #1025points at#1036, whose merge commit is73d2fae7and whose head is still the PASSed34278f3d.73d2fae7isplugins/social/test/social.test.js+55 −0and nothing else, and the file onmaincarries the case plus its three load-bearing assertions (the sync sits betweengrant_bot_to_friendand the roster refresh; the read names the Bot just granted, not the home; the store the panel renders already has the row when the accept returns). No source change, as scoped.changelog.d/fragment — test-only, per the scope Triage set;changelog.d/onmainis unchanged by this PR.Docs-not-needed:is in the branch commit and in the PR body (both places);plugins/social/isdocs/subsystems/social.md'sowned_paths, and nothing on that page describes this call, so the page stays as it is.Labels:
agent-workingremoved from#1025;agent-prremoved from#1036(passstays).Resolve the re-accept grant to the Bot the invite named (#1024)