I didn't have time to look into the concurrency / locking stuff – hoping that @tomek and @bartek can help there, as my time is increasingly limited starting now.

Sure! But probably it will be more efficient after the diff get split

This screen doesn't seem to match the design too closely. Is this something agreed with @ted?

It might be a good idea to also check that:

1. Pasting an URL with a QR code opens the right screen
2. Going back to a QR code screen opens it
3. Refreshing a QR code screen opens it
4. Opening a QR code screen as a logged-in user by pasting a URL doesn't open the screen (do we want that?)

I guess we could have a test plan here: e.g. create a job that fails and check if it gets retried. But if we follow what's in other workflows, we shouldn't expect any differences.

Agree with @marcin that introducing some utils encoding the contract is a good idea.

Seems reasonable, but I don't know Objective-C that well

Should we also create a migration that fixes pinned_count for threads affected by the fixed bug?

Avoid sleep before throwing

Clear cached flags after wipeAndExit

There's still a chance that the DB will get updated between select and update. One solution, as @atul suggested, might be to use transactions - which will work but might affect the performance. But there's another option: an update to multiple tables at once https://stackoverflow.com/questions/4361774/mysql-update-multiple-tables-with-one-query - can we use it?

Haven't reviewed all the changes too closely - there are a lot of them and they are really similar. All the important changes look good and the overall idea is great!

Rebase

Use uppercase and periods

In D8527#254913, @ashoat wrote:

Can you clarify what will happen on older clients when this endpoint returns a ServerError that they aren't aware of?

EDIT

Looks like on older clients it will display offensive_words directly. But D8494 makes it so if a future keyserver returns an unknown error code to a future client, unknown error will be displayed instead.

One additional thing to check might be Android - even though the theme doesn't apply there, it is worth checking if nothing breaks.

In D8562#254725, @kamil wrote:

In D8562#253200, @michal wrote:

Is there a chance that older web clients will still try to fetch this file?

No, there is not - if a site wasn't reloaded the file is there and a worker is operating on it, and if the site was reloaded this means the server sent new logic, which is not using this file.
Also, we are using contenthash, and this file is cached on the client anyway since its content did not change (likely this still might fail because browsers first need to hit keyserver to get a proper response but as I said - this should not happen).

Overall, I will probably wait with landing this for a couple of days to make sure it works, hosting this old file does not cause any harm but it'll make it easier to revert changes when something will go wrong.

In D8620#254184, @inka wrote:

Why should it work correctly? There is no explanation and no issue linked (I'm guessing there is some explanation in the issue). This is hard to review without any explanation, and this is the only diff in the stack, so it's not even possible to search for answers there

Looks ok but please make sure that we avoid duplicating style props.