Freshrss: Google Reader API Issue

[matthewvinton]

Hello all,

I am using FreshRSS with no issues with the Fever API, but cannot use the Reader API with any app I've tried. Details:

Version 1.15.0
Docker freshrss/freshrss

The API tests in "Profile" come back OK.

I have attempted to use both the latest version of Reeder, as well as FeedReader on Linux without success. They authenticate, but never actually return feed data into the app.

I am able to get information from the API using the example CURL commands.

When I attempt to use Reeder and refresh the feed list, I get the following logs in FreshRSS:

x.x.x.x - - [01/Nov/2019:09:32:34 -0600] "GET /api/greader.php/reader/api/0/subscription/list?output=json HTTP/1.0" 200 7416 "-" "Reeder/4020.19.05 CFNetwork/1120 Darwin/19.0.0"


x.x.x.x - - [01/Nov/2019:09:32:34 -0600] "GET /api/greader.php/reader/api/0/stream/items/ids?n=10000&xt=user/-/state/com.google/read&output=json&s=user/-/state/com.google/reading-list HTTP/1.0" 200 25019 "-" "Reeder/4020.19.05 CFNetwork/1120 Darwin/19.0.0"

[gothick]

I don't know if this is relevant, but I haven't been able to get my Reeder client (using Reader API) to acknowledge any new items since upgrading FreshRSS to 1.15.0. I can't see any errors in the server error log when I try to refresh, but haven't had a chance to investigate further yet.

FreshRSS appears to be working fine through the web interface, but even with plenty of unread items, a refresh in the Reeder client shows no new articles.

[Alkarex]

Please uncomment the following lines:

https://github.com/FreshRSS/FreshRSS/blob/0cc2c4628c4c6f16dd78acdb417982d3325485d3/p/api/greader.php#L900-L901

And check the logs in ./data/users/_/log_api.txt

Did any client worked for you with FreshRSS 1.14.x which does not work anymore with 1.15.0?

I cannot test Reeder myself.

[matthewvinton]

OK, I have enabled the debugging. Is there particular pieces of the log that would be helpful? Nothing is jumping out to me as being problematic.

As for earlier version, I did not test Reeder with the Greader API before 1.15.0 as I was aware of a couple of at least one issue with how it authenticated.

However, I did attempt to use FeedReader on Linux with 1.14.x without success. It claims that the server is offline.

[Qrizzz]

I experience the same issue. 1.14.3 worked fine with Reeder and Greader API.

[gothick]

Still investigating (and I'm very new to the Google Reader API in general and FreshRSS in particular, so forgive me if I'm jumping to conclusions!)

I noticed using a forensic log in Apache and the Reeder output in my macOS Console that when Reeder queried /api/greader.php/reader/api/0/stream/items/ids, it would then show a "Type Mismatch" error which seemed to be talking about the IDs of the items received.

The items were returned from the API as integers in the JSON, e.g.

{"itemRefs":[{"id":1572638017615972},...

Looking at the Google Reader specs, it seems to ask us to treat item IDs as opaque string blobs, even though they may be simple integers. I made a quick hack to return the item IDs from /stream/items/ids as string values, and when the items were returned like this:

{"itemRefs":[{"id":"1572638017615972"},...

...Reeder magically started working again.

Without knowing for sure about how the API's meant to work, though, I don't know if this indicates an issue with FreshRSS or with Reeder being a bit too fussy about the values it receives as item ids. I'm just hoping this sheds some light on the problem with someone who knows more about this!

[Alkarex]

Please try this candidate fix https://github.com/FreshRSS/FreshRSS/pull/2621

@gothick and @Qrizzz Are you also deploying FreshRSS using Docker and the freshrss/freshrss image? Are you all using MySQL? The change might be due to the use of native MySQL statements from https://github.com/FreshRSS/FreshRSS/pull/2522 , which in some conditions will return the native types (i.e. Int64).

@gothick Thanks for the great debugging 👍

Indeed, we could force this ID to be a string.

It is a string in the example from https://www.inoreader.com/developers/item-ids

In all client implementations I can find, it looks like both integer and string variants are accepted:

https://github.com/noinnion/newsplus/blob/2ce0002c8f4cea594fe1208922e1f4f184e98eb2/extensions/GoogleReaderCloneExtension/src/com/noinnion/android/newsplus/extension/google_reader/GoogleReaderClient.java#L890

https://github.com/Alkarex/EasyRSS/blob/8eeb64c12dc3feeeb67cf1d20eba92ee56d65b4b/src/org/freshrss/easyrss/data/parser/ItemIdJSONParser.java#L52-L58

https://github.com/ViennaRSS/vienna-rss/blob/35181a4f8fc6e4eb25523ebc35b85a7a06a6c85e/Vienna/Sources/Fetching/OpenReader.m#L742

https://github.com/jangernert/FeedReader/blob/6905f466acb4b0fefd7f6269940202ff389a52dc/plugins/backend/inoreader/InoReaderAPI.vala#L292

[gothick]

No problem 👍

Your candidate fix is exactly the change I made locally to test my theory, so I guess I've already confirmed it works for me :) I don't know if I've exercised the whole API, but I've deleted and successfully recreated the FreshRSS account in Reeder, and fetching articles and marking as read is definitely working.

I'm not using Docker (my server is a little more old fashioned) but I am using MySQL, so I think your theory about a native type now propagating out would fit the facts.

[matthewvinton]

The fix resolved the issue for me. Very nicely done!

[Alkarex]

@matthewvinton Great, and after this fix (which is now merged in /dev), please open another issue for FeedReader if there is still another problem there (I have not tested it recently)