It breaks the testsuite 'sometime' which is fairly annoying.
The whole testuite setup is crap though and likely needs to be
fixed first.
Will re-revert the changes once a new stable release of the app
is done.
Stream::for_each terminated the stream upon the first error. This
was causing feeds to not update if any one returned a non-200ish
result. To work around this, we create a succesfull result for
every entry regardless at the end.
While we are at it, aslo switch from FuturesOrdered stream
to FuturesUnordered. There is no reason to use Ordered, this was
a typo initially.
Use the proper Stream API to return a future to run on the
executor. Previously I was using a workaround to convert the
Stream into a future and run it to completion in the Executor,
since I was not aware of a better API.
This commit add a new DataError Variant for feeds that return 304.
Its expected behaviror and the current API of Source::into_feed
is kinda limiting the return type to make it easier to handle.
Up till now 304 was returning an Error to early return. Ideally
Source::into_feed will return a Multi variant Result Enum.
example:
enum FeedResult {
Ok(Success(feed)),
Ok(NotModified),
Err(err),
}
Hopefully in a refactor in the near Future™
Till then we will just have to match and ignore
DataError::FeedNotModified.
This reverts commit e64883eecb
and 40dd2d6923
Seems like core.run() returns once its done even if there
are still tasks in the Runtime underneath. A way to solve that
would be to call the shutdown_on_idle method.
We need ownership of the threadpool in order to invoke
`shutdown_on_idle` method but core.runtime only returns a
referrence so we need to create our own threadpool.
This requires a RUSTFLAG to be set before hand for rayon to build.
This brakes a lot of tools like rls and clippy by default and
require special configs for itnegration.
Additionally, rayon_futures is still 0.1 and not much work seem
to have gone into it. Ideally it should be replased with the tokio
runtime/threadpool.
This is never used anywhere else apart from the testsuite. Instead
of ignoring etags we should instead not save them if the feed does
not return 200 or 304. See #64.
