At startup, bridges onboard every user even though most of them have been idle forever

I'm staff on multiple IRC networks with bridges (small bridges and large ones) where the bridge's connection block has a limit and the bridges are configured to respect the limit.

There is increasing frustration at bridges that due to lazyjoining, at startup, onboard every. single. user. ever.

This can result in channels and server notices being flooded for days on end with thousands upon thousands of lines of connections cycling old connections off for subsequent ones. For example:

03:10:12 --> PersonDiscord[m] (@discord_1111111111111111111:domain.org) (~discord111@1.2.3.4) has joined #channel
03:10:16 <-- user[m] (~userdomai@1.2.3.4) has quit (quit: Client limit exceeded: 50)
03:10:22 --> usrDiscord[m] (@discord_2222222222222222222:domain.org) (~discord222@1.2.3.4) has joined #channel
03:10:26 <-- name[m] (~namedomai@1.2.3.4) has quit (quit: Client limit exceeded: 50)

I've spoken with some bridge operators who have the ignoreIdleUsersOnStartup setting set and are quite frustrated that this is ignored.

As I do not have access to a bridge myself, I cannot give any insight.

Is this a regression of #1142 or is this >3yo #1240 issue documenting the solution? I've not managed to get answers.

If so, I have big concerns about the potential consequences of having the debug API on; given the bridge's documented security track record. I would be very adverse to requiring bridge owners to do this. I will be particularly unhappy if this is the actual solution here.

Debugging needing to be on at all times is irresponsible, and doing so should never be required that for a basic courtesy/QoL thing.

matrix-org / matrix-appservice-irc

At startup, bridges onboard every user even though most of them have been idle forever #1808