When a web or queue worker exited unexpectedly, the new restarted worker would
not have any mode set and so would try to do web and queue worker stuff at the
same time, which was not the intended behaviour.
Changelog: Fixed
A cache for instances already exists and is exported there. Also the
type annotation here seemed wrong anyway because there did not seem to
be a way for that fetcher to actually ever return `null` as a value.
This should hopefully relieve some of the massive hammering on the
database when mass delivery jobs are running.
However, this also means that instance blocks are applied with a
slight delay on delivery queue. Since the settings page in the
native frontend already warns about this, I think it should be fine.
And the maximum time an instance block would be delayed would be
somewhere around 5min which IMO is also tolerable.
Changelog: Changed
TBH I'm still not quite convinced that this is really necessary but also
since treating an id mismatch like a redirect, I also don't think it
should break anything.
This makes `redirects` contain the number of remaining redirects, which
makes it easier to limit the number of further redirects that should be
allowed.
Especially in the case where the private key is used in an "array deliver",
it makes sense to only get the private key once instead of having the overhead
of fetching the key for each HTTP request.
ActivityPub requests on routes which do not support activitypub
are now replying with HTTP status code 406 "Not Acceptable".
ActivityPub clients are required by the W3C TR to set the `Accept`
header. If this accept header is detected on an unexpected route,
the whole request will be aborted with the status code above.
This is an additional measure for clients who might not be aware of
having to check the content-type header of the reply.
Ref: https://github.com/w3c/activitypub/issues/432
Changelog: Security
The user was already deleted from the user cache, so requesting the
user returned null. Because the key was not null, there was a non-null
return, in turn making further code think, fetching the user was
successful.
This can be useful when adding a feature for admins and moderators
where they will be able to immediately deal with their own report,
i.e. forwarding it to the other instance.
Changelog: Added
It does not make sense to re-request the same resource with the same
parameters and expect a different content-type to be returned. Also
this makes the error message more sensible and understandable.
Matching IP addresses against Regex does not seem like a smart idea.
Also it depends on ipaddr.js so that is already in the dependency
tree for us anyway.
> wild, it seems they had a bug about A/AAAA fallback a while ago but the
> way they fixed it is "v6 if v4 fails", not the other way around
>
> https://github.com/szmarczak/cacheable-lookup/issues/27
> b2348d5aed
>
> javascript community pls
-- @sn0w@cofe.rocks
The change in the emoji export logic should fix the case where emoji
packs exported with Foundkey should be used in any other Misskey fork.
I've opted not to change the import logic and instead document the
strange behaviour because it would also not be accepted by Misskey.
This translation seems to have been already a joke when it was added but
since it cannot be maintained any more, it will be removed.
Changelog: Removed