Page MenuHomePhabricator

Reduce impact of DiscussionTools API polling request (new messages)
Closed, ResolvedPublic

Description

DT polls every 5s for new messages to show (1) the new message warning and (2) the parent-comment-deleted error.

If a user leaves a browser window open for an hour they could run into API rate limits, leaving them unable to do anything else.

Possible solutions:

  • Using slower polling for anons
  • Disable polling for anons
  • Pause polling when no keyboard / mouse events detected for X seconds.

Derived Requirements

  • Ensure that DiscussionTools continues to detect and notify users when a new comment is posted in a thread while they have a Reply Tool widget open.
  • Ensure that polling pauses after 5 minutes without mouse or keyboard activity to reduce unnecessary API requests.
  • Ensure that consecutive polling failures increase the delay before subsequent polling attempts instead of continuing to poll every 5 seconds.
  • Ensure that polling stops entirely after 17 consecutive failures when the next polling delay would exceed one hour.

Test Steps

Test Case 1: Ensure polling detects new comments while the Reply Tool is open

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Keep the Reply Tool open and remain active on the page.
  4. From a separate user account or browser session, post a new comment in the same thread.
  5. Wait for the thread update polling to detect the new comment.
  6. Observe the Reply Tool.
  7. ✅❓❌⬜ AC1: A new-message notice appears when another user posts a new comment in the thread while the Reply Tool is open.

Test Case 2: Ensure polling pauses after 5 minutes of inactivity

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Open the browser's network monitoring tools and identify the thread update polling requests.
  4. Stop all mouse and keyboard interaction with the page.
  5. Wait for at least 5 minutes.
  6. Observe the network activity.
  7. ✅❓❌⬜ AC2: Thread update polling pauses after 5 minutes without mouse or keyboard activity.

Test Case 3: Ensure polling uses an increasing delay after consecutive failures

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Remain active on the page throughout the test.
  4. Use an appropriate test method to cause consecutive thread update polling requests to fail.
  5. Observe the timing between each subsequent polling request.
  6. ✅❓❌⬜ AC3: The delay between polling requests increases after each consecutive failure instead of continuing to poll every 5 seconds.

Test Case 4: Ensure polling stops after 17 consecutive failures

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Remain active on the page throughout the test.
  4. Use an appropriate test method to cause 17 consecutive thread update polling requests to fail.
  5. Allow each retry attempt to occur according to its increased delay.
  6. After the 17th consecutive failure, observe subsequent network activity.
  7. ✅❓❌⬜ AC4: Thread update polling stops after 17 consecutive failures when the next polling delay would exceed one hour.

QA Results - TesetWiki

Event Timeline

Change #1277110 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Create separate class for polling

https://gerrit.wikimedia.org/r/1277110

The above patch also adds a pause if there is no keyboard/mouse input for 5 minutes.

Did anyone think about using WebSocket? As far as I remember, Phabricator uses it, so it should be possible to do WebSocket in PHP, even though WebSocket is stateful while PHP is mostly stateless.

DLynch moved this task from Code review to QA on the Editing-team (FY2026-27 Q1 sprint 4) board.
DLynch subscribed.

Patch merged on July 30th, the bot just didn't update it.

QA needs to make sure that the poll-for-thread-updates behavior still works. (The notice that appears if you have a replywidget open and then someone else posts a new comment in the thread you're replying to.) Further validation would involve making sure that polling pauses when the user isn't active (no mouse/keyboard events in 5 minutes), and that the back-off-on-failure behavior works -- rather than just keeping on polling every 5 seconds, it increases the timeout with every failure. If it fails enough times in a row that the next delay would be more than an hour (17 failures, taking ~4 hours to reach) it'll just stop polling entirely. (Insofar as the user would *also* need to be "active" for that entire time, I think this isn't the most likely case to reach, but...)

@Esanders @DLynch Validated, Please review AC4

Test Result - TestWiki

Status: ✅ PASS ❌ FAIL
Environment: TestWiki
OS: macOS Tahoe 26.5.2
Browser: Chrome 151
Device: MBA
Emulated Device: NA

Test Artifact(s):

  • DiscussionTools Reply Tool
  • Browser Developer Tools or network monitoring tools
  • Two user accounts or sessions for posting and detecting new comments

Test Steps

Test Case 1: Ensure polling detects new comments while the Reply Tool is open

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Keep the Reply Tool open and remain active on the page.
  4. From a separate user account or browser session, post a new comment in the same thread.
  5. Wait for the thread update polling to detect the new comment.
  6. Observe the Reply Tool.
  7. ✅ AC1: A new-message notice appears when another user posts a new comment in the thread while the Reply Tool is open.

Test Case 2: Ensure polling pauses after 5 minutes of inactivity

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Open the browser's network monitoring tools and identify the thread update polling requests.
  4. Stop all mouse and keyboard interaction with the page.
  5. Wait for at least 5 minutes.
  6. Observe the network activity.
  7. ✅ AC2: Thread update polling pauses after 5 minutes without mouse or keyboard activity.

2026-08-31_17-07-51.png (2,178×1,255 px, 669 KB)

Test Case 3: Ensure polling uses an increasing delay after consecutive failures

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Remain active on the page throughout the test.
  4. Use an appropriate test method to cause consecutive thread update polling requests to fail.
  5. Observe the timing between each subsequent polling request.
  6. ✅ AC3: The delay between polling requests increases after each consecutive failure instead of continuing to poll every 5 seconds.

2026-08-31_18-27-27.png (2,159×1,245 px, 542 KB)

Test Case 4: Ensure polling stops after 17 consecutive failures

  1. Open a discussion page with DiscussionTools enabled.
  2. Open the Reply Tool for an existing comment.
  3. Remain active on the page throughout the test.
  4. Use an appropriate test method to cause 17 consecutive thread update polling requests to fail.
  5. Allow each retry attempt to occur according to its increased delay.
  6. After the 17th consecutive failure, observe subsequent network activity.
  7. ❌ AC4: Thread update polling stops after 17 consecutive failures when the next polling delay would exceed one hour.

I ran this last night and it stopped at 17 total but 14 failures. It also took a lot longer to do with the 14th failure taking 11 hrs.

2026-09-01_08-30-53.png (3,133×1,312 px, 549 KB)

I ran this last night and it stopped at 17 total but 14 failures. It also took a lot longer to do with the 14th failure taking 11 hrs.

I might have done the math wrong. 🤔

That said, I am suspicious about it even allowing that 11 hour failure to get queued. I will take a look.

I did indeed get the math sort-of wrong. I was right about the 17th try failing, but it should take 2.75 hours to get there. 4 hours would be how long it would take if the 17th try was allowed to continue.

There's not an obvious way that it could take 11 hours with the code as written, if an active state was successfully maintained. I have speculation that depends somewhat on what you were doing to keep the tab "active" for that long: if a retry timer finishes while the poller thinks it's paused it'll immediately requeue with the same interval it just tried, rather than just acting as soon as the user reactivates, so it's possible that poorly overlapping activity periods could make some of the longer delays have to retry themselves repeatedly.

(Note: "paused" and "inactive" are overlapping-but-separate. "paused" means "inactive or hidden", and "hidden" is measured by checking document.hidden, which will be true if various different "the user can't see the document" states are active. Of particular relevance is that I'm fairly sure that even if the browser window is in the foreground with focus it'll become "hidden" if a screensaver starts / the display sleeps.)

Change #1333487 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Poller: if a poll was skipped immediately run it when the user returns

https://gerrit.wikimedia.org/r/1333487

That patch (a) makes polls get retried immediately when the user returns if they were skipped due to being paused, and (b) adds a bunch of qunit tests of the poller behavior.

CleanShot 2026-09-01 at 23.44.06@2x.png (1,370×612 px, 216 KB)

Change #1333487 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Poller: if a poll was skipped immediately run it when the user returns

https://gerrit.wikimedia.org/r/1333487

Ok this looks much better now, as seen below. I will now mark this as Resolved. Thanks for all your work!

GMikesell-WMF edited projects, added: Verified; removed: Editing QA.
GMikesell-WMF updated the task description. (Show Details)