mastodon - Plural Café fork of Mastodon/Glitch Social

Age	Commit message (Collapse)	Author
2017-11-11	Retry thread resolving (#5599)	ThibG
	Thread resolving is one of the few tasks that isn't retried on failure. One common cause for failure of this task is a well-connected user replying to a toot from a little-connected user on a small instance: the small instance will get many requests at once, and will often fail to answer requests within the 10 seconds timeout used by Mastodon. This changes makes the ThreadResolveWorker retry a few times, with a rapidly-increasing time before retries and large random contribution in order to spread the load over time.
2017-04-04	Separate background jobs into different queues. ATTENTION: new queue "pull"	Eugen Rochko
	must be added to the Sidekiq invokation in your systemd file The pull queue will handle link crawling, thread resolving, and OStatus processing. Such tasks are more likely to hang for a longer time (due to network requests) so it is more sensible to not make the "in-house" tasks wait for them.
2017-01-05	Improve background jobs params and error handling	Eugen Rochko

2016-12-12	Restoring old async behaviour of thread resolving as it proved to be more robust	Eugen Rochko

2016-12-11	Thread resolving no longer needs to be separate from ProcessFeedService,	Eugen Rochko
	since that is only ever called in the background
2016-11-28	Adding embedded PuSH server	Eugen Rochko

2016-11-15	Fix rubocop issues, introduce usage of frozen literal to improve performance	Eugen Rochko

2016-09-29	Improve code style	Eugen Rochko

2016-09-21	Fix #24 - Thread resolving for remote statuses	Eugen Rochko
	This is a big one, so let me enumerate: Accounts as well as stream entry pages now contain Link headers that reference the Atom feed and Webfinger URL for the former and Atom entry for the latter. So you only need to HEAD those resources to get that information, no need to download and parse HTML <link>s. ProcessFeedService will now queue ThreadResolveWorker for each remote status that it cannot find otherwise. Furthermore, entries are now processed in reverse order (from bottom to top) in case a newer entry references a chronologically previous one. ThreadResolveWorker uses FetchRemoteStatusService to obtain a status and attach the child status it was queued for to it. FetchRemoteStatusService looks up the URL, first with a HEAD, tests if it's an Atom feed, in which case it processes it directly. Next for Link headers to the Atom feed, in which case that is fetched and processed. Lastly if it's HTML, it is checked for <link>s to the Atom feed, and if such is found, that is fetched and processed. The account for the status is derived from author/name attribute in the XML and the hostname in the URL (domain). FollowRemoteAccountService and ProcessFeedService are used. This means that potentially threads are resolved recursively until a dead-end is encountered, however it is performed asynchronously over background jobs, so it should be ok.