Commit graph

11 commits

Author SHA1 Message Date
Claire
95e9de5777
Prevent accidental serialization of Account and User records (#30079) 2024-04-29 09:45:58 +00:00
Claire
39da3d86f8
Fix ActiveRecord using two connection pools when no replica is defined (#27061) 2023-09-22 16:01:59 +02:00
Claire
2c204d904b
Change DB_REPLICA_* environment variables to REPLICA_DB_* (#26386) 2023-08-08 13:59:40 +02:00
Claire
3105fef21a
Rename “read” database to “replica” for consistency (#26326) 2023-08-03 16:17:09 +02:00
Claire
5cbc402687
Fix replica being used even if not explicitly defined (#26074) 2023-07-21 11:30:53 +02:00
Eugen Rochko
26e522ac55
Fix not actually connecting to the configured replica (#25977) 2023-07-17 08:26:52 +02:00
Eugen Rochko
5c42f47617
Fix records not being indexed sometimes (#12024)
It's possible that after commit callbacks were not firing when
exceptions occurred in the process. Also, the default Sidekiq
strategy does not push indexing jobs immediately, which is not
necessary and could be part of the issue too.
2019-10-01 01:19:11 +02:00
Eugen Rochko
115dab78f1
Change admin UI for hashtags and add back whitelisted trends (#11490)
Fix #271

Add back the `GET /api/v1/trends` API with the caveat that it does
not return tags that have not been allowed to trend by the staff.

When a hashtag begins to trend (internally) and that hashtag has
not been previously reviewed by the staff, the staff is notified.

The new admin UI for hashtags allows filtering hashtags by where
they are used (e.g. in the profile directory), whether they have
been reviewed or are pending reviewal, they show by how many people
the hashtag is used in the directory, how many people used it
today, how many statuses with it have been created today, and it
allows fixing the name of the hashtag to make it more readable.

The disallowed hashtags feature has been reworked. It is now
controlled from the admin UI for hashtags instead of from
the file `config/settings.yml`
2019-08-05 19:54:29 +02:00
Akihiko Odaki
40e5d2303b Validate HTTP response length while receiving (#6891)
to_s method of HTTP::Response keeps blocking while it receives the whole
content, no matter how it is big. This means it may waste time to receive
unacceptably large files. It may also consume memory and disk in the
process. This solves the inefficency by checking response length while
receiving.
2018-03-26 14:02:10 +02:00
Eugen Rochko
fdc17bea58 Fix rubocop issues, introduce usage of frozen literal to improve performance 2016-11-15 16:56:29 +01:00
Eugen Rochko
10ba09f546 Upgrade to Rails 5.0.0.1 2016-08-17 17:58:00 +02:00