In some rare cases, when receiving statuses out of order from the streaming
API then polling from the REST API, it was possible for the
`expandNormalizedTimeline` function to remove older items from the timeline.
This commit ensures that any item from the replaced slice that is older
than the oldest item retrieved from the API gets added back to the replaced
slice.
In some rare cases, when receiving statuses out of order from the streaming
API then polling from the REST API, it was possible for the
`expandNormalizedTimeline` function to remove older items from the timeline.
This commit ensures that any item from the replaced slice that is older
than the oldest item retrieved from the API gets added back to the replaced
slice.
Conflicts:
- `app/controllers/concerns/sign_in_token_authentication_concern.rb`:
Upstream removed this file, while glitch-soc had changes to deal with
its theming system.
Removed the file like upstream did.
Conflicts:
- `app/controllers/concerns/sign_in_token_authentication_concern.rb`:
Upstream removed this file, while glitch-soc had changes to deal with
its theming system.
Removed the file like upstream did.
In some rare cases, when receiving statuses out of order from the streaming
API then polling from the REST API, it was possible for the
`expandNormalizedTimeline` function to insert duplicates in the timeline,
which would then result in several bugs.
This commits ensures that there are no duplicates inserted in the
timeline.
In some rare cases, when receiving statuses out of order from the streaming
API then polling from the REST API, it was possible for the
`expandNormalizedTimeline` function to insert duplicates in the timeline,
which would then result in several bugs.
This commits ensures that there are no duplicates inserted in the
timeline.
* Change post text edit to not be considered significant if it's identical after reformatting
* We don't need to clear previous change information anymore
* Require status edits to be explicit, except for poll tallies
* Fix tests
* Add some tests
* Add poll-related tests
* Add HTML-formatting related tests
* Change post text edit to not be considered significant if it's identical after reformatting
* We don't need to clear previous change information anymore
* Require status edits to be explicit, except for poll tallies
* Fix tests
* Add some tests
* Add poll-related tests
* Add HTML-formatting related tests
Not completely sure this could actually have any ill effect, but if
`RemoveStatusService` fails to acquire a lock in an
`ActivityPub::ProcessingWorker` job processing a `Delete`, the status
is currently discarded and causes a job failure but the next time the
job is attempted, it will skip deleting the status due to it being
discarded.
This commit makes the behavior of `RemoveStatusService` a bit more consistent
in case of failure to acquire the lock.
Not completely sure this could actually have any ill effect, but if
`RemoveStatusService` fails to acquire a lock in an
`ActivityPub::ProcessingWorker` job processing a `Delete`, the status
is currently discarded and causes a job failure but the next time the
job is attempted, it will skip deleting the status due to it being
discarded.
This commit makes the behavior of `RemoveStatusService` a bit more consistent
in case of failure to acquire the lock.
Fixes#17898
Since #17204, the admin API has only been available through the web
application because of the unconditional requirement to provide a valid CSRF
token.
This commit changes it back to `null_session`, which should make it work
both with session-based authentication (provided a CSRF token) and with a
bearer token.
Fixes#17898
Since #17204, the admin API has only been available through the web
application because of the unconditional requirement to provide a valid CSRF
token.
This commit changes it back to `null_session`, which should make it work
both with session-based authentication (provided a CSRF token) and with a
bearer token.
