Smalyshev added a comment.
The problem is not getting the change twice. The problem is since we don't have
the ending point, if we ask by time only we can't know if we have updates or
not. That means, if there are no updates but last 5 updates were at the same
timestamp, current code will ask
Manybubbles added a subscriber: Manybubbles.
Manybubbles added a comment.
I suspect its safe to use it rccontinue to set the rc_id minimum for now but
the point of these opaque continue operations is that they might change. If
we're ok with this just failing at some point then its ok.
I'm not
Manybubbles added a comment.
Got it. Makes sense to me.
TASK DETAIL
https://phabricator.wikimedia.org/T85103
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Smalyshev, Manybubbles
Cc: Manybubbles, Smalyshev, TechDragon, Addshore, JanZerebecki,
JanZerebecki added a comment.
We could just always store the continue parameters from the last API request as
it is intended and only after a full dump load do a few unnecessary but
harmless updates.
TASK DETAIL
https://phabricator.wikimedia.org/T85103
EMAIL PREFERENCES
JanZerebecki added a comment.
I think supporting revision for recentchanges would mean two queries, first one
to find the rc_id. So how about rc_id instead? (
https://www.mediawiki.org/wiki/Manual:Recentchanges_table )
Now it seems that the api already supports that, via rccontinue. Example:
Smalyshev added a comment.
Hmm, if timestamp|rc_id works then it should be enough for us. I'm not sure if
it's safe to use rccontinue while not actually continuing but if it is, then it
should work. I'll check.
TASK DETAIL
https://phabricator.wikimedia.org/T85103
REPLY HANDLER ACTIONS
