implement polling reports in synapse

[jesopo]

we already have a method for getting reports in to mjolnir by asking an nginx sitting in front of Synapse to redirect the report endpoint to mjolnir, but this seemed fiddly, specific to your reverse proxy, and on matrix.org we want reports to go in to both mjolnir and synapse, so for the time being we landed on this solution.

this polls synapse once a minute to grab any new reports and feeds them in to the same code flow that the reverse proxy intercepting method uses

[jesopo]

i think if we kept the polling delay at once-a-minute, using setInterval is fine, but if it wants to be much faster, we're better off doing setTimeout

[Gnuxie]

Looking good so far

[Yoric]

Please do not use setInterval. If the homeserver has a downtime, this can cause a thundering herd of requests when it returns.

[jimmackenzie]

Reviewing the PR description:

we already have a method for getting reports in to mjolnir by asking an nginx sitting in front of Synapse to redirect the report endpoint to mjolnir, but this seemed fiddly, specific to your reverse proxy, and on matrix.org we want reports to go in to both mjolnir and synapse, so for the time being we landed on this solution.

this polls synapse once a minute to grab any new reports and feeds them in to the same code flow that the reverse proxy intercepting method uses

Suggested changes

• Set out what the change does
  • e.g. This change polls Synapse once per minute to grab new abuse reports from users, and pulls them into Mjolnir. This allows us to send the reports to both the Synapse database and to Mjolnir, which we need for matrix.org
• Set out the options you considered
  • Using an nginx instance sitting in front of Synapse to reverse proxy the report endpoint to Mjolnir
  • Polling Synapse to bring reports from Synapse to Mjolnir
  • What the third choice was (rewriting how we handle reports iirc)
• Set out why you chose the option in this PR
  • It's quick, not implementation specific, doesn't require a separate dependency in nginx
• Set out out the risks and potential problems with this choice
  • We may need to rewrite how we handle reports anyway
  • Polling may be slower than we need
  • Polling may be more expensive than we want
  • Making changes to the polling interval involves x

That pattern gives a future troubleshooter a bunch of context about why we are making this change, and the other options that we have considered and discarded. If we're hooking into other code flows, I'd maybe link those up too (such as the code flow for the existing implementation) — it's easy enough to find them, but in a 4am incident, any thinking we save ourselves is a victory! It also makes it easier if we're onboarding other folks onto the team, or if other teams are looking at this code in the future.

[Gnuxie]

Getting closer

[Gnuxie]

Looks good to me.

unsure of whether we need to give this a dedicated test, i believe it is possible #259 (comment)

[Yoric]

Will you be surprised if I request tests? :)

[Yoric]

Looks like we're almost there!

Lots of trivial nitpicks, because I'm me, and a couple of actual remarks hidden in the middle.

[Yoric]

Looks good, thanks!
A few nits here and there.