api-bypass-rate-limit not working for admin user token

[CoMPaTech]

Description:

Didn't look like #13441 resembles the issue we had, opening this one.

A high-curling-rate script we run to adjust some settings automatically suddenly gets hit by the rate-limiter. This was working a couple of weeks ago so unfortunately I don't have a version to pin down to (we run snap-based install).

The curling user authenticates is both user and admin. My permission settings are still default (so api-bypass-rate-limit is enabled for admin and bot). Changing permissions and allowing users to also bypass doesn't have any effect.

Steps to reproduce:

1. curl to /api/v1/users.info using token
2. rinse/repeat
3. {"success":false,"error":"Error, too many requests. Please slow down. You must wait 26 seconds before trying this endpoint again. [error-too-many-requests]"}

Expected behavior:

With a user being admin and user, having generated an API key I should be able to perform curl queries without hitting the rate-limiter.

Actual behavior:

See steps to reproduce

Server Setup Information:

• Version of Rocket.Chat Server: 2.1.1
• Operating System: Ubuntu 18.0.4
• Deployment Method: snap
• Number of Running Instances: 1
• DB Replicaset Oplog: 161
• NodeJS Version: 8.15.1
• MongoDB Version:3.6.14

Client Setup Information

Command line curl (Ubuntu 18.0.4)

Additional context

Query users.info for other scripts and modifying settings

Relevant logs:

No (relevant) output in the logfiles that I'm aware of

[CoMPaTech]

Current workaround is to up the rate-limited default calls to 300, but I'd rather keep it at the default 10.

[frostbtn]

Same here, but for different endpoint (im.create).

Our Rocket is installed from snaps, version 2.1.1 is dated 2019-10-17. So after usual 1 month delay our server just got updated last weekend and our integrations stopped working.

As a workaround I've disabled rate limiter altogether (it's acceptable in my case): Administration - Rate Limiter.

[sshere]

Disabling the rate limiter has not had any resolution to this for myself. We have even raised the number of calls to 9999 and the time allowance to 1 and 0 to see if it would have any change.