mjolnir/test/integration/throttleTest.ts

34 lines
1.7 KiB
TypeScript
Raw Normal View History

import { strict as assert } from "assert";
Reduce the throttle test theshold even more. The implementation is rubbish, as it doesn't avoid the exponential backoff Remove default rate limit testing. It doesn't work. No there really isn't more to say about it you're welcome to dispute it if you're going to do the work investigating. I'm not. We used to have a test here that tested whether Mjolnir was going to carry out a redact order the default limits in a reasonable time scale. Now I think that's never going to happen without writing a new algorithm for respecting rate limiting. Which is not something there is time for. https://github.com/matrix-org/synapse/pull/13018 Synapse rate limits were broken and very permitting so that's why the current hack worked so well. Now it is not broken, so our rate limit handling is. https://github.com/matrix-org/mjolnir/commit/b850e4554c6cbc9456e23ab1a92ede547d044241 Honestly I don't think we can expect anyone to be able to use Mjolnir under default rate limits. well, it's not quite simple as broken, but it is broken. With the default level in synapse (which is what matrix.org uses) it is struggling to redact 15 messages within 5 minutes. that means 5 messages over the burst count. This is ofc ontop mjolnir sending reactions / responding to replies (which isn't much but... enough to mess with the rate limiter since ofc, Synapse tells requests to wait x amount of time before trying again, but that doesn't help for concurrent requests since ofc there's only 1 slot available at that future time. This means Synapse just wacks everything with exponentially longer shit without many (or any?) events going through it used to be fine because rate limiting in synapse used to be a lot more liberal because it was "broken" or something, that's not me saying it's broken that's just what synapse devs say which is probably true. if all requests went into a queue then yeah you could eliminate one problem but that's a lot of work and i don't think we should be doing it cos no one uses mjolnir like this anyways
2022-08-15 11:55:18 +00:00
import { newTestUser } from "./clientHelper";
import { getMessagesByUserIn } from "../../src/utils";
describe("Test: throttled users can function with Mjolnir.", function () {
it('throttled users survive being throttled by synapse', async function() {
let throttledUser = await newTestUser(this.config.homeserverUrl, { name: { contains: "throttled" }, isThrottled: true });
let throttledUserId = await throttledUser.getUserId();
let targetRoom = await throttledUser.createRoom();
// send enough messages to hit the rate limit.
await Promise.all([...Array(25).keys()].map((i) => throttledUser.sendMessage(targetRoom, {msgtype: 'm.text.', body: `Message #${i}`})));
let messageCount = 0;
await getMessagesByUserIn(throttledUser, throttledUserId, targetRoom, 25, (events) => {
messageCount += events.length;
});
assert.equal(messageCount, 25, "There should have been 25 messages in this room");
})
})
Reduce the throttle test theshold even more. The implementation is rubbish, as it doesn't avoid the exponential backoff Remove default rate limit testing. It doesn't work. No there really isn't more to say about it you're welcome to dispute it if you're going to do the work investigating. I'm not. We used to have a test here that tested whether Mjolnir was going to carry out a redact order the default limits in a reasonable time scale. Now I think that's never going to happen without writing a new algorithm for respecting rate limiting. Which is not something there is time for. https://github.com/matrix-org/synapse/pull/13018 Synapse rate limits were broken and very permitting so that's why the current hack worked so well. Now it is not broken, so our rate limit handling is. https://github.com/matrix-org/mjolnir/commit/b850e4554c6cbc9456e23ab1a92ede547d044241 Honestly I don't think we can expect anyone to be able to use Mjolnir under default rate limits. well, it's not quite simple as broken, but it is broken. With the default level in synapse (which is what matrix.org uses) it is struggling to redact 15 messages within 5 minutes. that means 5 messages over the burst count. This is ofc ontop mjolnir sending reactions / responding to replies (which isn't much but... enough to mess with the rate limiter since ofc, Synapse tells requests to wait x amount of time before trying again, but that doesn't help for concurrent requests since ofc there's only 1 slot available at that future time. This means Synapse just wacks everything with exponentially longer shit without many (or any?) events going through it used to be fine because rate limiting in synapse used to be a lot more liberal because it was "broken" or something, that's not me saying it's broken that's just what synapse devs say which is probably true. if all requests went into a queue then yeah you could eliminate one problem but that's a lot of work and i don't think we should be doing it cos no one uses mjolnir like this anyways
2022-08-15 11:55:18 +00:00
/**
* We used to have a test here that tested whether Mjolnir was going to carry out a redact order the default limits in a reasonable time scale.
* Now I think that's never going to happen without writing a new algorithm for respecting rate limiting.
* Which is not something there is time for.
*
* https://github.com/matrix-org/synapse/pull/13018
*
* Synapse rate limits were broken and very permitting so that's why the current hack worked so well.
* Now it is not broken, so our rate limit handling is.
*
* https://github.com/matrix-org/mjolnir/commit/b850e4554c6cbc9456e23ab1a92ede547d044241
*
* Honestly I don't think we can expect anyone to be able to use Mjolnir under default rate limits.
*/