Erik Johnston
Erik Johnston
One potential cause to look into is if we're correctly timing out connections/requests. If we have a fixed connection pool then its possible all connections get stuck for an age.
@turt2live suggests that there is other work that might need to be done before we can remove the v1 APIs, but he'd need to go and spend some time figuring...
Related: https://github.com/matrix-org/sydent/issues/287
There seems to be three sets of HTTP servers, do we expect this option to apply to all of them or just the client API one?
That looks to be because the request timed out. Maybe the internet or Google had a blip or something :shrug: I'm not sure why we log the stack trace though,...
I think this is just a case of removing `exc_info=True` here: https://github.com/matrix-org/sygnal/blob/214497a1584c37e57f01499628d123ed984bd271/sygnal/gcmpushkin.py#L398-L402 And also adding `exc` to the log line.
The fix here is to give the `LoggingContext()` on line 296 a name
Yes, it is expected that the compressor may produce slightly more rows, *especially* if its run on a room that has previously been compressed. We should probably handle that case...
The clippy lint will be fixed by ~~#92~~ #91 The test failure is annoying, as it looks like the test cases that we're using ends up generating the same number...
The optimal setting depends on the room, and basically impossible to guess without trying different values. IME the default levels are usually good, if not necessarily the best. https://github.com/matrix-org/rust-synapse-compress-state/blob/main/docs/algorithm.md has...