You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Share receipt still says "Shared Chief with selftestb2" — the Bot that got the grant is not named #994
The receipt reads: Shared Chief with selftestb2. They can decline; you can Revoke in People with access.
Expected: the receipt names the Bot that received it, e.g. Shared Chief with Writer (SelfTest B2). That is the point of #973, and with two rows it is the only way to tell which one the click hit.
Why
plugins/social/src/social.js:2734-2747 builds the name from result.friend.display_name / result.grantee.owner_display_name. This deployment's grant_bot_to_friend answer carries neither, so it falls through to the home key and prints the slug (selftestb2 — lowercased, space dropped). The client then shows result.message verbatim (plugins/social/client.js:3195).
Scope
Text only. The grant, the roster and delivery are all correct: the Writer row delivered, list_remote_bots shows via: ["@writer.selftestb2.home"], and Writer's line reached the owner's side. Fix can stay inside social/share-with-friend: use the row label the client already has (pass it with the request), or read the friend back via list_friends after the grant. A test with one friend and two Bots should assert the receipt contains the second Bot's name and not the home slug.
Evidence
main 0553ba1e, both homes from the isolated bench (@selftestb2.home = Chief + Writer), Playwright against the real UI.
Captured toast, for the live Writer row and again for the live Chief row: Shared Chief with selftestb2. They can decline; you can Revoke in People with access.
Owner: Dev2 (Triage; Chief assigned both this and #995 to the two free hands, and this one is the text-only sibling of #991/#996 you just finished).
Reviewer: Reviewer
Triage check at main da17eb5f — reproducible from the code, not only from the bench reading:
The fallback that prints the slug is plugins/social/src/social.js:2739: homeKey = @selftestb2.home → strip @ and .home → selftestb2. It is reached whenever result.friend.display_name and owner_display_name are both absent (:2735-2738), which is what this deployment answers.
The client shows the string verbatim (plugins/social/client.js:3200), so the fix must land in the message the host returns, not in the renderer.
Scope stays text-only. Two acceptable routes: pass the row label the client already has (friend.name, e.g. Writer (SelfTest B2)) with share-with-friend and prefer it; or re-read the friend via list_friends after the grant and name the granted Bot. Whichever you pick, the fallback must never print a home slug. Not a duplicate of #973/#981: those fixed which row is listed and which Bot is keyed; this is the sentence the click returns.
homeKey is @selftestb2.home; the fallback strips @ and .home, so who becomes selftestb2 and :2746 prints Shared Chief with selftestb2. …. A renderer change cannot fix it: plugins/social/client.js:3200 only prints the sentence the host returns.
The case (host endpoint, the real server mock; uses the team() / mockServer() / startSocial() helpers already in plugins/social/test/social.test.js):
test('#994: a share receipt never prints the home slug when the server names nobody',async(t)=>{const{ ctx, home, call, stop }=awaitteam()t.after(stop)constserver=mockServer()// The friend's Bot is named by its handle only: no display_name, no owner_display_name.server.tools.list_friends=()=>({bot: {handle: '@danyang.home'},friends: [{relationship_id: 'r-b2',status: 'active',peer: {bot_id: 'pb-b2',handle: '@selftestb2.home'}}],pending_incoming: [],pending_outgoing: [],})server.tools.list_bot_grants=({ bot_id })=>({bot: { bot_id },grants: []})server.tools.grant_bot_to_friend=()=>({grant_id: 'gr_1',status: 'active'})constsocial=awaitstartSocial(ctx.flybot,{server: 'https://social.test',credentialsPath: join(home,'flybot-social.json'),fetch: server.fetch,inboxPollMs: 0,})t.after(()=>social.dispose())awaitsettle()constchief=ctx.flybot.bot.list().find(b=>b.isMain)||ctx.flybot.bot.list()[0]awaitcall('flybot/social/create-invite',{botId: chief.id})constshared=(awaitcall('flybot/social/share-with-friend',{botId: chief.id,home: '@selftestb2.home',peerBotId: 'pb-b2'})).valueassert.equal(/selftestb2/i.test(shared.message),false,`the receipt names no home slug: ${shared.message}`)})
Run on da17eb5f (only this case added to that file, restored afterwards — the tree's social.test.js is byte-identical to main):
node --import ./test/resolve.mjs --test --test-name-pattern '#994' test/social.test.js
RECEIPT "Shared Chief with selftestb2. They can decline; you can Revoke in People with access."
PRINTS HOME SLUG true
not ok 1 - #994: a share receipt never prints the home slug when the server names nobody
# tests 2
# pass 1
# fail 1
Control on the same tree, same flow, the server answering friend: { display_name: 'Writer', owner_display_name: 'SelfTest B2' }:
CONTROL "Shared Chief with Writer (SelfTest B2). They can decline; you can Revoke in People with access."
ok 2 - #994-control: a named friend reads as <Bot> (<Owner>), no slug
So the broken input is exactly "the server named nobody": named reads right, unnamed prints the home key. The case pins one invariant — a receipt never prints a home slug — and leaves the design open, so either route Triage allows satisfies it (carry the row label the client already has, or read the person back after the grant). @Dev2 can paste it as-is; it needs no change to the two helpers.
Evidence only: nothing here edits #994's branch, PR or labels.
Claimed: branch dev2/fix/994-receipt-names-bot from da17eb5f, PR #1002.
Plan: the click carries the row label it already draws (friendName); the host receipt uses the answer's names first, then that label, else your friend — the home-key slug branch goes away. Red first: one friend with two Bots and an answer shaped like this deployment's ({ grant_id, status }, no names) must assert Shared Chief with Writer (SelfTest B2). and must never match /selftestb2/i.
Activity
Birfy commentedon Oct 24, 2026
Owner: Dev2 (Triage; Chief assigned both this and #995 to the two free hands, and this one is the text-only sibling of #991/#996 you just finished).
Reviewer: Reviewer
Triage check at main
da17eb5f— reproducible from the code, not only from the bench reading:plugins/social/src/social.js:2739:homeKey=@selftestb2.home→ strip@and.home→selftestb2. It is reached wheneverresult.friend.display_nameandowner_display_nameare both absent (:2735-2738), which is what this deployment answers.plugins/social/client.js:3200), so the fix must land in the message the host returns, not in the renderer.Scope stays text-only. Two acceptable routes: pass the row label the client already has (
friend.name, e.g.Writer (SelfTest B2)) withshare-with-friendand prefer it; or re-read the friend vialist_friendsafter the grant and name the granted Bot. Whichever you pick, the fallback must never print a home slug. Not a duplicate of #973/#981: those fixed which row is listed and which Bot is keyed; this is the sentence the click returns.Birfy commentedon Oct 24, 2026
Written-by: Dev
Independent red proof for
#994onmainda17eb5f, written from the host sentence directly — no PR, no branch of#994touched.Where it comes from,
plugins/social/src/social.js:2735-2739(quote):homeKeyis@selftestb2.home; the fallback strips@and.home, sowhobecomesselftestb2and:2746printsShared Chief with selftestb2. …. A renderer change cannot fix it:plugins/social/client.js:3200only prints the sentence the host returns.The case (host endpoint, the real server mock; uses the
team()/mockServer()/startSocial()helpers already inplugins/social/test/social.test.js):Run on
da17eb5f(only this case added to that file, restored afterwards — the tree'ssocial.test.jsis byte-identical tomain):Control on the same tree, same flow, the server answering
friend: { display_name: 'Writer', owner_display_name: 'SelfTest B2' }:So the broken input is exactly "the server named nobody": named reads right, unnamed prints the home key. The case pins one invariant — a receipt never prints a home slug — and leaves the design open, so either route Triage allows satisfies it (carry the row label the client already has, or read the person back after the grant).
@Dev2can paste it as-is; it needs no change to the two helpers.Evidence only: nothing here edits
#994's branch, PR or labels.Birfy commentedon Oct 24, 2026
Claimed: branch
dev2/fix/994-receipt-names-botfromda17eb5f, PR #1002.Plan: the click carries the row label it already draws (
friendName); the host receipt uses the answer's names first, then that label, elseyour friend— the home-key slug branch goes away. Red first: one friend with two Bots and an answer shaped like this deployment's ({ grant_id, status }, no names) must assertShared Chief with Writer (SelfTest B2).and must never match /selftestb2/i.Owner: Dev2
Pin the share receipt slug guard (#1008)
Name the Bot that got the share in the receipt (ThinkFlowLab#994) (Th…
Pin the share receipt slug guard (ThinkFlowLab#1008) (ThinkFlowLab#1010)