Should I merge it now? Yes.
Yes.
Commit dc5f52683a91 closes the two ways send could run without a real permission result. GitHub still reports a clean merge and zero check runs. The test plan in the description is still unchecked. I would merge it anyway, then click through the list on the hotfix.
What the new commit fixes
The earlier head ce0dc226ae62 set dmValidations to null, then unlocked broadcast and followers in the same turn. sendMessage read dmValidations.minTipKeys whenever a custom tip amount was set. Opening a mailing list did not clear that amount. Enter threw.
The minimum tip now goes through dmValidations?.minTipKeys, and falls back to minimumTip when permissions are null. requestParamsofBroadcast calls closeTipPopup before history loads, so the custom amount is gone. The emoji button uses areMessageActionsLocked too.
If generateGroudId rejects, or the response has no group id, both loaders stop, permissionsFailed stays true, and dmValidations is cleared. The same lock applies when the receiver id is missing. Retry is still checkNewUserValidation. Send stays disabled until that call returns status: true.
this.dmValidations?.minTipKeys?.min_tip_guaranteed_reply || this.minimumTipGuarded tip read · Fail closed when the group id never arrives
Inbox refetch
Sending on an existing direct message used to call getUserChatLogs just to move that row. updateUserList now rewrites the matching row's preview, last_message.timeStamp, and updated_at. It refetches only when that group id is missing from every tab.
An incoming message on the open thread updates the transcript and the direct-message tabs, and skips getUserChatLogs. A message for a different thread still refetches the inbox. History keeps its own cancel subject, so that refetch cannot drop the open transcript.
A mailing list you just sent still refetches when the send socket reports status. An incoming mailing-list message, while that list is open, updates the transcript and leaves the left-hand row where it was. The row already exists in the broadcast tab, so the new "missing from every tab" check does not refetch it.
What I traced
| Path | Send while permissions are unknown |
|---|---|
Direct message from a row, ?user=, tip-back id | Validation runs. Send stays locked until it returns. |
| Fast thread switch, or an inbox refetch | historyCancel$ and the sid check drop a late history body. |
Validation error, status: false, or an empty receiver id | permissionsFailed stays set. Retry is required. |
| Mailing list after a custom tip on a direct message | Tip popup closes. The null read is gone. |
| Group id request fails, then Retry succeeds | Send unlocks after validation. sid can still be empty, because Retry does not create the group again. |
What I did not run
- I read
dc5f52683a91againstce0dc226ae62on 5 October 2026. - I did not run the app, the unit tests, or a white-label build. The pull request has no status checks.
ngAfterViewCheckedstill callsdetectChangesevery cycle. The description says that removal was skipped on purpose.
After merge, open a creator thread, switch threads quickly, fail validation and hit Retry, and open a mailing list after filling a custom tip.