Too many reactions on a single post quickly get
spammy, so they are now sorted by count and only
the first MAX_REACTIONS number of different
emojis are actually displayed.
the maximum number of reactions was previously
hardcoded to 8. this commit also fixes an
incorrect query in StatusReactionValidator where
it didn't count per-user reactions but the total
amount of different ones.
* Add missing locale keys
Added missing translation keys to en.js to make translation easier and more complete.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
* Remove translation keys for explore
Have been added to vanilla in #2014
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
* Remove unused key
Sorry, originally worked on this on my custom fork, which has this key, before I decided to work on glitch.
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Signed-off-by: Plastikmensch <plastikmensch@users.noreply.github.com>
Upstream does not have a column heading for “Posts and replies”, but the
text itself exists in a similar context, so re-use that translatable
string so that we can use upstream's translations.
Conflicts:
- `README.md`:
Discarded upstream changes: we have our own README
- `app/controllers/follower_accounts_controller.rb`:
Port upstream's minor refactoring
There is an idempotency key generated by clients when authoring a post,
and stored in Redis, to ensure that if a user or client retries posting
the same status, we don't get a duplicate.
Hachyderm.io has been experiencing some filesystem and database
performance issues, causing database writes to be slow. This can mean
that there are successful posts, but the reverse proxy returns 504
Gateway Timeout before the idempotency status has been updated; users or
clients who retry (such as Tusky which retries automatically, see
tuskyapp/Tusky#2951) can re-try the same post with the same idempotency
key before it has actually been recorded in Redis, leading to duplicate
posts.
To address this issue, move all of the database updates after the
initial transaction that creates the status into the
`postprocess_status!` method, so we can insert the idempotency key
immediately after the status has been created, significantly reducing
the window in which the status could be created but the idempotency key
not yet stored.
Note: this has not yet been tested; I'm submitting this PR for
discussion and to offer to the Hachyderm.io admins to try out to fix the
multiple posting problem.
Co-authored-by: Brian Campbell <brcampbell@beta.team>
