VersionControl:PRs/magenta/410: Difference between revisions
From PickiPedia: A knowledge base of bluegrass, old time psychedelic jams, and other public domain music
Jump to navigationJump to search
cryptograss/magenta#410, as GitHub has it |
cryptograss/magenta#410, as GitHub has it |
||
| Line 16: | Line 16: | ||
|deploy= | |deploy= | ||
}} | }} | ||
<pre class="pr-body">Justin, 6 Nov: clicking a notice for a three-word message at the end of the Mood he was already in put "finding it…" over the whole thread for about 10 s. | |||
**Why:** on the live server a poll (`/turns/?after=`) takes 4 to 6 s right now (measured 6 Nov: 4.3 s and 6.5 s; `?from=` 1.3 s), and the page polls every 4 s, so one is nearly always in flight. `reveal()` joined that in-flight poll, but it had been asked before the notice's message landed, so its answer lacked the message. reveal then reached back with `?from=` under the mask and swapped the thread for a window at the message: 6 s waiting on the stale poll, then 4 s more behind the mask. | |||
**Fix:** when the message isn't drawn and a poll was already out, reveal waits for it and then asks once more, fresh. That one brings the message, and the thread is kept, no mask. Only if a fresh poll still lacks it does reveal reach back as before. | |||
Tests: 1723 pass. Checked on a scratch copy with Playwright, a bell notice for a message the page hadn't drawn, and the first poll held and emptied to play the stale one: with the fix, two polls, no `?from=`, the message appears in place and the mask never shows. With the message withheld from every poll, it still falls back to `?from=`. | |||
The underlying slowness of `?after=` is still there and is the next thing to look at (it's the activities scan per poll, I think, but I haven't profiled it against the live database). | |||
Redeploy: maybelle | |||
Worked on by: magent and Justin, in #notifications</pre> | |||
Latest revision as of 16:06, 9 November 2026
| State | 🟣 merged 2026-11-07 03:15:02 |
|---|---|
| Worked on by | magent, justin |
| Moods | #notifications |
| Deploy | not said |
| Branch | reveal-fast → main, by magent-cryptograss
|
| Opened · last pushed | 2026-11-06 17:56:05 · 2026-11-06 17:56:01 |
Justin, 6 Nov: clicking a notice for a three-word message at the end of the Mood he was already in put "finding it…" over the whole thread for about 10 s. **Why:** on the live server a poll (`/turns/?after=`) takes 4 to 6 s right now (measured 6 Nov: 4.3 s and 6.5 s; `?from=` 1.3 s), and the page polls every 4 s, so one is nearly always in flight. `reveal()` joined that in-flight poll, but it had been asked before the notice's message landed, so its answer lacked the message. reveal then reached back with `?from=` under the mask and swapped the thread for a window at the message: 6 s waiting on the stale poll, then 4 s more behind the mask. **Fix:** when the message isn't drawn and a poll was already out, reveal waits for it and then asks once more, fresh. That one brings the message, and the thread is kept, no mask. Only if a fresh poll still lacks it does reveal reach back as before. Tests: 1723 pass. Checked on a scratch copy with Playwright, a bell notice for a message the page hadn't drawn, and the first poll held and emptied to play the stale one: with the fix, two polls, no `?from=`, the message appears in place and the mask never shows. With the message withheld from every poll, it still falls back to `?from=`. The underlying slowness of `?after=` is still there and is the next thing to look at (it's the activities scan per poll, I think, but I haven't profiled it against the live database). Redeploy: maybelle Worked on by: magent and Justin, in #notifications