Convert more endpoints to the read-only follower database

[jtgeibel]

r? @pietroalbini

[Turbo87]

do we have some docs somewhere that explain when to use which DB?

[jtgeibel]

I've pushed another commit to this PR, converting even more GET endpoints over. A word of caution, we need to test this well in staging (the new commit is live there now). I can split the 2nd commit off into its own PR if we decide that is safer.

The reason is, we can't catch these bugs in CI. When running tests, everything happens inside a single transaction that is eventually discarded, so all endpoints accessed in a single test have to go through the same connection. It's possible we could switch the 1 connection between read-only and read-write during an individual test, but we don't have the test infrastructure in place for that.

The staging environment is set up such that it defines a READ_ONLY_REPLICA_URL pointing to the primary database. In this configuration, if an endpoint is incorrectly converted to the follower database then we will report (and log) errors about the read-only connection.

do we have some docs somewhere that explain when to use which DB?

The general rule of thumb I have is that anything GET should be idempotent and could be eligible for the follower database. Of course there are some exceptions, notably the download endpoint which increments the download count.

I think we should also avoid converting endpoints related to authentication. While there should only ever be a slight delay on the follower database, we don't want a user who just logged in to have issues accessing /me endpoints for example.

[jtgeibel]

I've tested all these endpoints on staging, and didn't see any issues. It actually took me a little while to figure out the API of the 2 deprecated routes. I believe we can remove these routes, as I see no activity on them in the logs from the last month, but for now they are converted to the follower, for whatever that is worth.

[Turbo87]

LGTM 👍

the only thing I'm a little bit worried about is the potential loss of consistency from using the slightly delayed read replica of the database. this could potentially mean that if the frontend modified something and then queried for the same resource it could still see the old data. I don't know how long that delay is in practice though.

(feel free to r=me)

[jtgeibel]

@bors r=Turbo87

(Merging now, going to deploy this separately from the current deploy.)

[bors]

📌 Commit aea4457 has been approved by Turbo87

[bors]

⌛ Testing commit aea4457 with merge 1c65ab3...

[bors]

☀️ Test successful - checks-actions
Approved by: Turbo87
Pushing 1c65ab3 to master...