"Viewing an error"

[Kruzya]

Affected version

2.2.7

As said in title.

After upgrade to XF 2.2.7, my staff members started to complain on "viewing an error" when users view some threads.
I didn't pay attention at first, but looked into DB into this moment, and noticed view_state is error when all another looks good. User 100% can view thread, because node, where thread is placed, available for everyone.


Sometimes this text also applies to staff members too. Sometimes to simple users.


Also i noticed another strange moment: user can open thread, and they displays as "normal". Some time later after user inactivity, they receive "viewing an error" mark.

Firstly, all looks like we're have problems with threads. But 15 minutes ago i received bug report with resources. And i really see this behavior:


This behavior has never been seen on 2.2.6 patch 2.
I'm totally sorry for russian language on screenshots. They captured in different time. I'll try replace later to english versions where it is possible.

 

[Kirby]

Did you double check that the user can view thread ID 59309?

 

[Chris D]

At this moment in time it's not something we can reproduce here so further troubleshooting will be required. I can't currently see this being a bug as I don't recall us changing anything here for quite some time.

The view_state is set in XF\Pub\Controller\AbstractController::canUpdateSessionActivity.

Interestingly, this defaults to error so there's potentially scope for something falling through one of the conditions here and just defaulting to that but I'm not entirely sure, yet.

We run the $reply object being returned by the controller through get_class:

switch (get_class($reply))
{
   case 'XF\Mvc\Reply\Redirect':
   case 'XF\Mvc\Reply\Reroute':
      return false; // don't update anything, assume the next page will do it

   case 'XF\Mvc\Reply\Message':
   case 'XF\Mvc\Reply\View':
      $viewState = 'valid';
      break;
}

Notable thing here is if $reply isn't any of these it will fall through as an error. Depending on the use case that could borderline be a bug. The other thing about this is get_class would return the exact class of the reply object, ignoring any parent classes. So if $reply was actually class SomeAddOn\XF\Mvc\Reply\MyView extends View then this wouldn't match. That said, we don't allow these classes to be extended using class extensions so it would actually require overriding the view method of the controller and returning a different object entirely which is not something we would expect.

Then we check for an error in the response:

if ($reply->getResponseCode() >= 400)
{
   $viewState = 'error';
}

In the code, I'm not seeing anything totally suspicious here, but clearly disabling all add-ons and monitoring for a while should at least rule that out.

 

[Kruzya]

Did you double check that the user can view thread ID 59309?

Yes, we're sure: this user can view this thread, because sometimes this "exclamation" isn't showed, it can "appends" later to status, like something updates user session activity.
Also we installed [MMO] Impersonate User add-on and checked through him. Thread is fully visible.

Chris, thanks for response.
Disable all add-ons - is too hard for our board, we're have many customizations implemented via custom add-ons, and some of them, unfortunately, altered tables without default values, which can cause database exceptions because "no default value".

I reviewed class extensions list, and no one add-on doesn't extends canUpdateSessionActivity() method in XFRM:ResourceItem and XF:Thread controllers. What i need look next?