- Порезанный
- 2 сентября 2026 г. в 01:42 UTC
- Автор
- Kamo
- Обещать
- 8ccc308
POST /sessions/{guid}/messages is @Transactional, and the NATS publish of the message has always waited for the commit — with a comment saying exactly why: publishing inside the transaction races the recipient's own read of the row. The two STOMP announcements ten lines below it did not wait, and they are the ones with a reader on the other end. /topic/chat/incoming/{memberId} is answered by a member with no window open by OPENING one, which loads the thread's history over a separate request; that read regularly reached the database before the sender's commit, so the window flew open holding everything except the message that had opened it, and stayed wrong until something re-read the thread. Closing and reopening the window was the workaround, which is how it was reported. /topic/chat/unread/{memberId} rides with it and had the mirror-image problem: a count of a message no other request could yet see. Both now run in runAfterCommit(), registered after the NATS synchronization so an already-open window still gets the message first and the badge second. The recipient ids and their org ids are resolved before registering, while the entities are still attached; the payloads were already plain values. AnnounceAfterCommitRatchetTest pins it by brace-matching the post-commit regions and requiring both topics to fall inside one, so the next announcement added here has to make the choice deliberately rather than by copying the nearest line. It fails on the two lines this commit moves.