Page MenuHomePhabricator

Flow InvalidDataException on action=history with offset
Open, LowPublicPRODUCTION ERROR

Description

https://www.mediawiki.org/w/index.php?action=history&offset=20160126191716&title=Talk%3AMediaWiki

Updated link: https://www.mediawiki.org/w/index.php?title=Project:Support_desk&action=history&offset=20160126191716

log error:

{"id":"WBEe@wpAMFIAACjuEZsAAABL","type":"Flow\\Exception\\InvalidDataException","file":"/srv/mediawiki/php-1.28.0-wmf.23/extensions/Flow/includes/Data/Pager/HistoryPager.php","line":50,"message":"Unable to load history for skt7uo1dwlujk8w5","code":"fail-l

SeverityUser is shown an exception page
FrequencyNot sure, because we don't log these anymore (rEFLW0380275b7757: Catch InvalidDataException errors to avoid log spam)
Level of effort to fixLow. Someone would need to track down where offsets are processed and probably silently discard invalid ones, or offer a nicer error page to the end user
Consequences if we don't do thisUsers continue to see (limited) exception details on the error page

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Mattflaschen-WMF It seems that &offset does not work at all for Flow pages. wikitext pages are fine.

In betalbs:
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:ET1&action=history&offset=20160126191716 gives

Error
Failed to load history content.

Return to Main Page

[WBI8LgpEE4AAABrTdIYAAAAE] /w/index.php?title=Talk:ET1&action=history&offset=20160126191716 Flow\Exception\InvalidDataException from line 50 of /srv/mediawiki/php-master/extensions/Flow/includes/Data/Pager/HistoryPager.php: Unable to load history for sgvxzba9rj7wph5k

Backtrace:

#0 /srv/mediawiki/php-master/extensions/Flow/includes/Block/BoardHistory.php(60): Flow\Data\Pager\HistoryPager->doQuery()
#1 /srv/mediawiki/php-master/extensions/Flow/includes/View.php(193): Flow\Block\BoardHistoryBlock->renderApi(array)
#2 /srv/mediawiki/php-master/extensions/Flow/includes/View.php(68): Flow\View->buildApiResponse(Flow\WorkflowLoader, array, string, array)
#3 /srv/mediawiki/php-master/extensions/Flow/includes/Actions/Action.php(112): Flow\View->show(Flow\WorkflowLoader, string)
#4 /srv/mediawiki/php-master/extensions/Flow/includes/Actions/Action.php(50): Flow\Actions\FlowAction->showForAction(string)
#5 /srv/mediawiki/php-master/includes/MediaWiki.php(505): Flow\Actions\FlowAction->show()
#6 /srv/mediawiki/php-master/includes/MediaWiki.php(289): MediaWiki->performAction(Article, Title)
#7 /srv/mediawiki/php-master/includes/MediaWiki.php(861): MediaWiki->performRequest()
#8 /srv/mediawiki/php-master/includes/MediaWiki.php(522): MediaWiki->main()
#9 /srv/mediawiki/php-master/index.php(43): MediaWiki->run()
#10 /srv/mediawiki/w/index.php(3): include(string)
#11 {main}

Strangely, Flow uses base-64 encoded thingies (UUIDs? UUID prefixes?) for the offset parameter: https://www.mediawiki.org/w/index.php?title=Talk:MediaWiki&offset=t612gdknsqwnvnra&action=history is what you get when you click "(older 50)".

So we should probably at least accept timestamps here. Ideally we'd paginate based on the same thing as the wikitext history page, but I guess pagination based on timestamps might not work if there are multiple things with the same timestamp; UUIDs don't have that problem.

@Matanya Did you assemble that URL yourself, or did the UI link you to it (doesn't seem so)?

The UI did it, you can see other hit that too, by looking in the logs on flourine/logstash.

@Matanya Could you post a URL (where the broken link itself is), and a screenshot, and circle (or otherwise clarify) where the link is in the UI?

I am wondering if it's generated by a gadget.

I agree accepting timestamps would be nice, but it's lower priority.

I don't remember. All i remember is i clicked it in some page and got the exception. I agree it is low priority.

Just to clarify - 'Error Failed to load history content.' is present in betalabs Flow pages when &offset is used according to https://meta.wikimedia.org/wiki/Help:Page_history.
Help:Page history suggests users to use timestamp

To only show edits before a given date and time [...].

Using timestamps in &offset for Flow pages causes the error page.

However, I could not find the cases when &offset=timestamp for flow pages/posts can be done directly from UI.
@Matanya - I'll check 'View history' &offset for Topics/Posts Permalinks (also for Resolved/Hidden topics/posts).

As @Catrope said, the &offset for Flow pages has a different format.

e.g.
Clicked on 'View (newer 100)' on the wikitext page- https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Mavetuna&dir=prev&offset=20150223220435&limit=100&action=history -- no errors

Clicked on 'View (newer 100)' on the Flow page
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=Talk:ET8&dir=prev&offset=t9gze19ww5hjo8rv&limit=100&action=history -- no errors

Unassigning myself until this is reproducible via a UI click.

jmatazzoni added a subscriber: jmatazzoni.

Let's just fix the documentation to say "don't do this."

Krinkle renamed this task from [bug] flow fatal in 1.28.0-wmf.23 - to Flow InvalidDataException on aciton=history with offset.Sep 1 2018, 1:28 AM
Krinkle renamed this task from Flow InvalidDataException on aciton=history with offset to Flow InvalidDataException on action=history with offset.
Krinkle lowered the priority of this task from High to Medium.
Krinkle added a project: Growth-Team.

I'm not familiar with this code, but it sounds like there is some amount of consensus to not support the behaviour that the code is currently trying but failing to offer.

If that is the case, a simple and adequate solution would be to patch BoardHistory to explicitly reject the user action. It could do so with roughly the same error message as now (or better). This would make a significant improvement code-wise because it means that this issue will be recorded by our infrastructure as "a user tried something we don't support".

Currently, however, it gets logged as "MediaWiki may be broken" – with escalation paths that eventually lead to pager duties and automatic deployment prevention.

mmodell changed the subtype of this task from "Task" to "Production Error".Aug 28 2019, 11:11 PM
kostajh added a subscriber: kostajh.

Production error, so we should implement the suggestion for T149251#4579330 instead of deferring this indefinitely. Moving to Q2 accordingly.

Krinkle removed a subscriber: Krinkle.
kostajh lowered the priority of this task from Medium to Low.Sep 14 2021, 12:10 PM

Lowering the priority; presence of this error during train rollout should not be cause for alarm. Still agreed on the solution in T149251#4579330, if someone wants to make a patch, Growth-Team could look at it.