Repository navigation
fix(tapbacks): a failure is said even if Blip closed while it ran - #139
Merged
Merged
Conversation
The imsg-react run lived in the BlipView that started it, and both the popout surface and the app window are destroyed on close. On a macOS 27 gateway a run takes 15-75 s, so closing Blip mid-run took the Process and its exit with it: the failure, with its reason on stderr, was never shown. The run now lives in BarWidget (runTapback, reactProc), which outlives both surfaces. Every exit is a tapbackExited(chat, ok) signal; a failure also waits in tapbackFailures[chat] until a view showing that conversation takes it (takeTapbackFailure), at once if it is on screen, otherwise when the conversation is next opened in either surface. A new tapback drops an older failure for the same conversation. imsg-react: on macOS 27 the newest-message check now runs before Messages is touched, so a tapback on an older message is refused in about a second without bringing Messages forward. Verified: on a 27.0.1 gateway, a tapback on an older message showed "tapback: on this macOS only the newest message in a conversation can take a tapback" (react.log: not-last exit=65). test_react.py 60 pass, bun test 750 pass.
Owner
|
Merged, thank you Ian, and for closing your own loose end from #138 the same night. Moving the run into the bar widget is the right owner: a 15-75 s run on macOS 27 was always going to outlive a closed window, and a failure that waits for its conversation beats one that vanishes. Refusing an older message before Messages comes forward is a nice touch too. 750 tests and every bridge test green; live on my Mac and both Linux machines. |
nixfred
added a commit
that referenced
this pull request
Oct 8, 2026
LR-T: blip, change-log, weekly-notes, #139, tapbacks, ianswope LR-D: blip Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BeRMdPWNC2myz9U8hEeeCi
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to the "not addressed" note on #138.
Cause
The
imsg-reactProcess lived in theBlipViewthat started it. The popout's surface and the app window are both destroyed on close, and on a macOS 27 gateway a run takes 15-75 s. Close Blip mid-run and the Process went with the view, so its exit, and the reason on stderr, never reached the status line.Fix
BarWidget(runTapback,reactProc), which outlives both surfaces. One run at a time, as before.tapbackExited(chat, ok). On success a view on that chat settles its pending pill exactly as before.tapbackFailures[chat]until a view showing that conversation takes it (takeTapbackFailure): immediately if it is on screen, otherwise when the conversation is next opened, in the popout or the window. This replaces the view-localtapbackNote. A new tapback drops an older failure for the same chat.sawExit) moves with the Process.imsg-react: on macOS 27 the newest-message check now runs before Messages is touched, so a tapback on an older message is refused in about a second without bringing Messages forward or opening the conversation.Verified
tapback: on this macOS only the newest message in a conversation can take a tapbackin the status line;react.log:not-last exit=65.tapbacks.test.tsasserts the new wiring, including thatBlipViewno longer ownsreactProc.test_react.py60 pass (the not-last refusal now also asserts the conversation was never opened).bun test750 pass.