* Make BackupService resilient to read timeouts
If an attachment read times out, assume that the resources is
inaccessible and continue the backup without it. This fixes#12280.
* Both errors on one line
* Make BackupService resilient to read timeouts
If an attachment read times out, assume that the resources is
inaccessible and continue the backup without it. This fixes#12280.
* Both errors on one line
* Summary: fix slowness due to layout thrashing when reloading a large set of status updates
in order to limit the maximum size of a status in a list view (e.g. the home timeline), so as to avoid having to scroll all the way through an abnormally large status update (see https://github.com/tootsuite/mastodon/pull/8205), the following steps are taken:
•the element containing the status is rendered in the browser
•its height is calculated, to determine if it exceeds the maximum height threshold.
Unfortunately for performance, these steps are carried out in the componentDidMount(/Update) method, which also performs style modifications on the element. The combination of height request and style modification during javascript evaluation in the browser leads to layout-thrashing, where the elements are repeatedly re-laid-out (see https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing & https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers).
The solution implemented here is to memoize the collapsed state in Redux the first time the status is seen (e.g. when fetched as part of a small batch, to populate the home timeline) , so that on subsequent re-renders, the value can be queried, rather than recalculated. This strategy is derived from https://github.com/tootsuite/mastodon/pull/4439 & https://github.com/tootsuite/mastodon/pull/4909, and should resolve https://github.com/tootsuite/mastodon/issues/12455.
Andrew Lin (https://github.com/onethreeseven) is thanked for his assistance in root cause analysis and solution brainstorming
* remove getSnapshotBeforeUpdate from status
* remove componentWillUnmount from status
* persist last-intersected status update and restore when ScrollableList is restored
e.g. when navigating from home-timeline to a status conversational thread and <Back again
* cache currently-viewing status id to avoid calling redux with identical value
* refactor collapse toggle to pass explicit boolean
* Summary: fix slowness due to layout thrashing when reloading a large set of status updates
in order to limit the maximum size of a status in a list view (e.g. the home timeline), so as to avoid having to scroll all the way through an abnormally large status update (see https://github.com/tootsuite/mastodon/pull/8205), the following steps are taken:
•the element containing the status is rendered in the browser
•its height is calculated, to determine if it exceeds the maximum height threshold.
Unfortunately for performance, these steps are carried out in the componentDidMount(/Update) method, which also performs style modifications on the element. The combination of height request and style modification during javascript evaluation in the browser leads to layout-thrashing, where the elements are repeatedly re-laid-out (see https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing & https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Performance_best_practices_for_Firefox_fe_engineers).
The solution implemented here is to memoize the collapsed state in Redux the first time the status is seen (e.g. when fetched as part of a small batch, to populate the home timeline) , so that on subsequent re-renders, the value can be queried, rather than recalculated. This strategy is derived from https://github.com/tootsuite/mastodon/pull/4439 & https://github.com/tootsuite/mastodon/pull/4909, and should resolve https://github.com/tootsuite/mastodon/issues/12455.
Andrew Lin (https://github.com/onethreeseven) is thanked for his assistance in root cause analysis and solution brainstorming
* remove getSnapshotBeforeUpdate from status
* remove componentWillUnmount from status
* persist last-intersected status update and restore when ScrollableList is restored
e.g. when navigating from home-timeline to a status conversational thread and <Back again
* cache currently-viewing status id to avoid calling redux with identical value
* refactor collapse toggle to pass explicit boolean
Fixes#12690
The `strong_migrations` update from f673e3d120
introduced a check for `change_column_null` specific to Postgres. This rejects
old migrations.
This commit just wraps old migrations with `safety_assured` to bypass this
check. Alternatives would have been to:
- Disable that check entirely (a possibility added in that same
`strong_migrations` version) for Mastodon, but it makes sense to write new
migrations without such a strong lock.
- Rewrite the old migrations to do it in a way that do not require an exclusive
lock. I thought fixing those old migrations for performance wasn't worth the
pain. Also, if I understand correctly, the next version of
`strong_migrations` is going to include a helper to do that. We could update
those migrations at that point.
Fixes#12690
The `strong_migrations` update from ba2eac8824
introduced a check for `change_column_null` specific to Postgres. This rejects
old migrations.
This commit just wraps old migrations with `safety_assured` to bypass this
check. Alternatives would have been to:
- Disable that check entirely (a possibility added in that same
`strong_migrations` version) for Mastodon, but it makes sense to write new
migrations without such a strong lock.
- Rewrite the old migrations to do it in a way that do not require an exclusive
lock. I thought fixing those old migrations for performance wasn't worth the
pain. Also, if I understand correctly, the next version of
`strong_migrations` is going to include a helper to do that. We could update
those migrations at that point.
