Last modified: 2012-12-31 11:30:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T42481, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 40481 - Fatal error when trying to mark certain edits as patrolled on en.wikt: "Call to a member function getText() on a non-object"
Fatal error when trying to mark certain edits as patrolled on en.wikt: "Call ...
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Patrolling (Other open bugs)
1.20.x
All All
: Normal normal with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-24 18:22 UTC by Ran Ari-Gur (User:Ruakh on WMF projects)
Modified: 2012-12-31 11:30 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Ran Ari-Gur (User:Ruakh on WMF projects) 2012-09-24 18:22:13 UTC
On the English Wiktionary, when I click a "Mark as patrolled" link for some edits, I get a fatal error with these details:

> PHP fatal error in /usr/local/apache/common-local/php-1.20wmf12/includes/Message.php line 605:
> Call to a member function getText() on a non-object

Observations:

- The error prevents the edit from being marked as patrolled. (Furthermore, the UI error-message persists even after an edit is marked as patrolled via the API -- more on that below -- so the error must be taking place before the UI even gets to the point of trying to mark the edit as patrolled.)

- This seems to be tied to the specific edit: the majority of edits do not trigger this error, but if an edit *does* trigger this error, it will do so consistently: every time I visit its mark-as-patrolled page, I get the same error.

- I haven't observed a pattern to which edits are affected, but if anyone offers a predictive theory, I can try to confirm or refute it.

- This problem does *not* affect the mark-as-patrolled API call. This offers a partial workaround, since we have site JavaScript that creates mark-as-patrolled buttons in various places, and those buttons use the API rather than the UI; but still, but it's not always very easy to get to one of those places to find the button for a specific edit that you've tried and failed to mark as patrolled.

- This is *not* caused by expiring patrol-tokens. If I reload the page that contains the "Mark as patrolled" link, it will continue to give me a link that uses the same patrol-token.
Comment 1 Ran Ari-Gur (User:Ruakh on WMF projects) 2012-09-24 20:40:39 UTC
I forgot to mention:

- This affects other admins as well.

- This started several days ago. I don't remember exactly when.

- I've also seen a similar-looking error for rollbacks, just a small number of times, but I don't know if that's the same thing. (I didn't save the details.)

- See discussion at http://en.wiktionary.org/wiki/Wiktionary:Grease_pit/2012/September#.22Mark_as_patrolled.22_often_gives_errors.3B_sometimes_.22rollback.22_does.2C_too.
Comment 2 Andre Klapper 2012-12-19 17:27:41 UTC
Ran: Can this problem still be seen on en.wikt?
Comment 3 Ran Ari-Gur (User:Ruakh on WMF projects) 2012-12-24 21:46:49 UTC
Andre: Due a recent MediaWiki change, clicking normally on a "Mark as patrolled" link now invokes JavaScript that submits an API request, rather than actually loading index.php?title=...&action=markpatrolled&rcid=...&token=... (at least if you have JavaScript enabled, as I do); so while I haven't seen this error in a while, I also haven't had any opportunity to see it in the normal course of events.

However, since seeing your question here, I've tested a few dozen times (by using "Open in New Tab" rather than simply clicking on the links), and I didn't see this error even once. So if you want to close this, feel free, and if/when I ever hear of this happening again, I can re-open it (or just open a new ticket).

Thanks.
Comment 4 Andre Klapper 2012-12-31 11:30:09 UTC
Thanks for retesting. CLosing as WORKSFORME for the time being, but please reopen if you see this again.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links