Thursday morning I noticed that the fedwiki river was stuck and only showing 4 items from one wiki. It was an outpost and the timestamps in the sitemap were updated on every reload, keeping it perpetually stuck to the top.
My theory is that River5 was having problems with a feed and it prevented it from outputting anything once it hit that bug.
I decided that although River5 is an excellent piece of software, in this context it was adding a layer of complexity that I didn't need. Especially since one of my next projects is to generate rivers from any roster.
I decided to refactor the feeds app and do the aggregating myself. I still provide the river.json format that River5 produces but I no longer depend on River5.
Next up will be some changes to how I'm handling caching. Most functions in my app allow a parameter "preferCache" and if there is a cache available, it will return it without checking for new data.
I'd like to update this to take an enum rather than a binary value. That way I can specify more granularity with: 0=OnlyFresh 1=CachedOnFailure 2=PreferCache 3=OnlyCache
There are some endpoints that depend on data from many endpoints (like a river or peer list) and I'd prefer if the live endpoints only used cached data, returning a different status code if it was a new wiki and we didn't have data yet.