Page MenuHomePhabricator

Flow: NULL workflow in UrlGenerator exceptions from NotificationFormatter
Closed, ResolvedPublic

Description

We're getting roughly one "$workflow is not UUID or Workflow instance" exception a day in production from includes/UrlGenerator.php, triggered either from a notification API query or Special:Notifications.

BasicFormatter is passing a NULL workflow to generateUrlData(), so I guess the event object's getExtra() didn't contain the expected 'topic-workflow' key, or it was null.

It might be worth catching the exception, logging it in a Flow file, and returning a dummy formatter rather than aborting the other user notifications. (If that's what's happening.)

Here's one of the exceptions from the notification API query. You have to be logged in, and if I paste the URL it seems to work, so to reproduce we'd have to try to find the user(s) with the troublesome notifications. I wonder if it could be notifications regarding a deleted or suppressed workflow.

2014-03-03 19:26:00 mw1145 enwiki: [5c973112] /w/api.php?action=query&format=json&meta=notifications&notformat=flyout&notlimit=7&notprop=index%7Clist%7Ccount&_=1393874759279 Exception from line 144 of /usr/local/apache/common-local/php-1.23wmf15/extensions/Flow/includes/UrlGenerator.php: $workflow is not UUID or Workflow instance
#0 /usr/local/apache/common-local/php-1.23wmf15/extensions/Flow/includes/Notifications/Formatter.php(39): Flow\UrlGenerator->generateUrlData(NULL, 'view')
#1 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/formatters/BasicFormatter.php(647): Flow\NotificationFormatter->processParam(Object(EchoEvent), 'post-permalink', Object(Message), Object(User))
#2 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/formatters/BasicFormatter.php(361): EchoBasicFormatter->processParams(Array, Object(EchoEvent), Object(Message), Object(User))
#3 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/formatters/BasicFormatter.php(260): EchoBasicFormatter->formatFragment(Array, Object(EchoEvent), Object(User))
#4 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/formatters/BasicFormatter.php(222): EchoBasicFormatter->formatNotificationTitle(Object(EchoEvent), Object(User))
#5 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/controller/NotificationController.php(338): EchoBasicFormatter->format(Object(EchoEvent), Object(User), 'web')
#6 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/api/ApiEchoNotifications.php(144): EchoNotificationController::formatNotification(Object(EchoEvent), Object(User), 'flyout')
#7 /usr/local/apache/common-local/php-1.23wmf15/extensions/Echo/api/ApiEchoNotifications.php(26): ApiEchoNotifications::getNotifications(Object(User), 'flyout', 8, NULL)
#8 /usr/local/apache/common-local/php-1.23wmf15/includes/api/ApiQuery.php(279): ApiEchoNotifications->execute()
#9 /usr/local/apache/common-local/php-1.23wmf15/includes/api/ApiMain.php(861): ApiQuery->execute()
#10 /usr/local/apache/common-local/php-1.23wmf15/includes/api/ApiMain.php(362): ApiMain->executeAction()
#11 /usr/local/apache/common-local/php-1.23wmf15/includes/api/ApiMain.php(333): ApiMain->executeActionWithErrorHandling()
#12 /usr/local/apache/common-local/php-1.23wmf15/api.php(76): ApiMain->execute()
#13 /usr/local/apache/common-local/w/api.php(3): require('/usr/local/apac...')
#14 {main}


Version: master
Severity: normal

Details

Reference
bz62178

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 2:54 AM
bzimport set Reference to bz62178.
bzimport added a subscriber: Unknown Object (MLST).

The exceptions started 2014-02-19 11:51:00 (early Wednesday in SF) and are all on enwiki.

We can't proceed with this until someone comes forward to complain that Echo notifications for Flow aren't working right for them.

Five in the last 16 hours, all on enwiki, all from the meta=notifications API query.

I'm pretty sure that this was the issue where we were trying to store so much data (mostly revision content) in an Echo event, that Echo's DB column couldn't fully store it, so it couldn't be unserialized later on. This has been fixed for awhile.

Also, this bug hasn't gotten any follow-up reports since, so I'll consider this fixed.