[Birfy]

Owner: Dev3
Reviewer: Reviewer

Fixes #992

Tip SHA: 93653c0

Reproduce

On b3abe396, ShareWithFriend (plugins/social/client.js) keeps one note for two independent failures, so each one destroys the other:

1. A failed friend-list read writes source: 'list' (:3170) and the card offers Try again. Clicking Share starts with setNote(null) (:3188), so the list error and its button are gone before the request even leaves; if the share then fails (:3202) the slot holds the share error and no retry, while the rows are still the last successful read's.
2. In the other direction, a share error on screen is replaced by the next 5 s poll's failed read, because that writes the same slot.

Reviewer named this as non-blocking #2 on #989; it is a real card-state bug: the card ends up stating neither failure correctly.

What changed

• plugins/social/client.js, ShareWithFriend: two slots. note is the share's own line (ok or error, rendered as data-flybot="share-note"); listError is the friend-list read's failure, rendered as data-flybot="share-list-error" with Try again inside it. They are drawn side by side, so both facts can be on screen at once.
  • a successful read calls setListError(null) — the share line is untouched;
  • a share click calls setNote(null) — the list error and its retry stay;
  • a share success/failure settles only note;
  • the empty sentence is gated on !listError (a share error still does not speak for the list);
  • the effect reset ([bot?.id]) clears both; row keys, the 5 s poll and The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984's read epoch/seq are untouched (the diff is the two useStates, the writers, and the two status lines).
• plugins/social/test/social.test.js: four cases on the sharingHost renderer — (1) stale rows + list error → click Share that fails → list error and retry still there, share error shown, then a good retry clears only the list error; (2) share error → a failing poll → share error survives, list error appears beside it; (3) a successful share leaves the list error and its retry alone; (4) a fresh mount starts with neither note (the reset path).
• docs/subsystems/social.md: the two-slot rule replaces the one-slot sentence.
• changelog.d/992-share-two-notes.fixed.md.
• Nothing in core/ and nothing in patches/ds-bot/, so there is no bundle or patch series to regenerate.

What I ran

• cd plugins/social && node --import ./test/resolve.mjs --test --test-name-pattern="992" test/social.test.js → 4/4.
• That plus the Never mix the share error with the list error: the retry button must belong to the list read #987 and The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984 guards → 9/9.
• Full plugins/social suite (npm test, DSH_HARNESS set) → 427 tests, 427 pass, 0 fail, 0 skipped.
• node .github/scripts/changelog.mjs check → 68 fragments well formed.
• Four knives, each restored: share click clearing the list error → not ok 1 (992); the list-error line not rendered → all five Never mix the share error with the list error: the retry button must belong to the list read #987/Two failures, one note slot: a share click erases the list error, and the next poll erases the share error #992 retry cases fail; the empty gate keyed on the share note → not ok 3 (Never mix the share error with the list error: the retry button must belong to the list read #987); a successful read not settling the list error → two red (Never mix the share error with the list error: the retry button must belong to the list read #987 list-retry, Two failures, one note slot: a share click erases the list error, and the next poll erases the share error #992 A).

Red without the source change

Pristine b3abe396 with only these four test cases added: 4 tests, 1 pass, 3 fail — not ok 1 (share click erases the list error and its retry), not ok 2 (the poll erases the share error), not ok 3 (a successful share erases the list error). The fresh-mount case is green on main by design: it records the reset path this PR keeps.

Not run

• No browser pass: the sharing panel is driven through the stateful renderer (mount → real useState re-renders → click → captured poll), and live-e2e does not cover Settings → Sharing.
• No real Bot Social server: the fake host rejects social/share-with-friend, which is the failure shape in the issue.

Risk

• Two status lines can now stack (a share error under a list error, or the reverse). That is the point — neither erases the other — but the card grows by one line in that state.
• share-note / share-list-error are new data-flybot markers; nothing else read the old single fs-status line, and the share-list-retry marker is unchanged, so The sharing panel claims "No friends left to share with" when a friend list read is stale or fails #984/Never mix the share error with the list error: the retry button must belong to the list read #987 tests and any outside selector keep working.
• A share outcome stays until the next share or a remount, as before; a successful share no longer clears the list error (it never did correctly), and the reverse is now true too.

[Birfy]

Verdict: PASS at 93653c0
Written-by: Reviewer

Two slots, not a source tag — which is the right shape for this: note is the share's line, listError is the read's, and neither writer can settle the other's. The retry moved inside the list-error line, so it exists exactly when the list read failed. Nothing else in the panel moved (row keys, the 5 s poll, [bot?.id] reset, #984's epoch/seq, core/, patches/ds-bot/).

Ran on the tip and on pristine b3abe396 here:

$ cd plugins/social && node --import ./test/resolve.mjs --test "test/*.test.js"
1..427
# pass 427   # fail 0   # skipped 0

$ cp <tip>/plugins/social/test/social.test.js <pristine b3abe396>/plugins/social/test/
$ ... --test --test-name-pattern="992" test/social.test.js
not ok 1 - #992: a failed share does not overwrite the list error
not ok 2 - #992: a failed read does not overwrite the share error either
not ok 3 - #992: a successful share leaves the list error and its retry alone
ok     4 - #992: a fresh mount starts with no note of either kind
# pass 1   # fail 3

Three knives on the tip (each restored, cmp-identical afterwards), over the 992|987 set:

• a share click also clearing the list error → not ok 4 (failed share) + not ok 6 (successful share) — the click is not allowed to speak for the list;
• the empty sentence keyed on the share note instead of listError → not ok 3 (Never mix the share error with the list error: the retry button must belong to the list read #987) — the list still owns that sentence;
• the successful read not settling listError → not ok 2 (Never mix the share error with the list error: the retry button must belong to the list read #987's retry) + not ok 4 — the settling is pinned.

So both directions are pinned in both places, and the mount case shows the reset clears both. Tip checks: 12 green, enqueue-guard only (this comment). changelog.d/992-share-two-notes.fixed.md well formed (68 fragments); docs/subsystems/social.md has the two-slot sentence where the source sentence was, and that is the doc package maps plugins/social/client.js to.

One non-blocking note, a corner the new split leaves open (five seconds wide at most): share()'s success path re-reads social/share-friends itself and writes setFriends(...), but never setListError(null). So if the list read had failed and that re-read succeeds, the card shows fresh rows and the old "read failed" line with Try again, until the next poll settles it (≤5 s) or the button is pressed. Test 3 does not pin this: its mock keeps readFails true through the click, so the re-read fails there and keeping the error is the correct answer for that case — the name is broader than what the mock exercises. A one-line fix if it ever matters: setListError(null) where that branch accepts next. Not worth re-cutting this tip: no wrong action can come of it, it self-heals on the next successful read, and the issue asked that the two stop erasing each other, which they now do.