http - long-poll - EventQueueGet capability should not perform exponential backoff on 'failed' operations

[monty-linden]

Environment

7.2.1.17108480561/win64

Description

Discovered while reviewing disconnect logs from Strawberry:

https://lindenlab.slack.com/archives/C02R43FJP/p1757949291763609?thread_ts=1757688772.468139&cid=C02R43FJP

The viewer's EventQueueGet endpoint is currently using the request retry logic in llcorehttp to resent operations after receiving 499, 502, and other errors. This is a good practice for normal requests but not for these particular long-poll operations. Timeout errors are expected but the retry logic is inserting 16s or more delay between HTTP requests. This artificially delays the intake and processing of events sent on the event queue.

Simply disabling the retry feature on this class of traffic may be sufficient to improve the situation. Some detection and accommodation of runaway failures from a bad peer might be useful.

Reproduction steps

Review the log interpretation section of the slack discussion.

---

This repo is using Opire - what does it mean? 👇

💵 Everyone can add rewards for this issue commenting /reward 100 (replace 100 with the amount).
🕵️‍♂️ If someone starts working on this issue to earn the rewards, they can comment /try to let everyone know!
🙌 And when they open the PR, they can comment /claim #4685 either in the PR description or in a PR's comment.

🪙 Also, everyone can tip any user commenting /tip 20 @monty-linden (replace 20 with the amount, and @monty-linden with the user to tip).

📖 If you want to learn more, check out our documentation.

[monty-linden]

QA Guidance - The Prequel

And a warning... removing the delay should be a general benefit to all. But it will also bring race conditions to the front. Like http vs udp, or http vs async/threaded processing, etc. Be on the lookout for problems elsewhere and don't necessarily ignore 'weird things.'

[monty-linden]

QA Guidance

A note for testers of #4690. That PR fixes two things:

• This issue (delayed retry of EventQueueGet capability).
• Incorrect handling of certain status codes potentially leading to disconnect from simulators and/or the grid. The latter case taking the viewer to the B&W screen.

Testing the second one will be more than difficult. But now you know.

And this comes with a warning. Changes to LLEventPoll are high-risk. This one method in the class is 25% of the communications system between viewer and simulators. Sorta-okay doesn't cut it. I like the changes here but you'd be wise to enlist as much help as possible. People distant from us-west-2, on bad networks, with poor-quality android personal access points, satellite internet subscribers, users of vpns, those using socks and http proxies.