Uncaught exception due to Google login handler issues

[Colonel_mortis]

TypeError: Cannot access offset of type string on string (0)
#0 /opt/forum/system/Login/Handler/OAuth2/Google.php(299): IPS\Login\Handler\OAuth2\_Google->_userData()
#1 /opt/forum/applications/core/modules/front/system/settings.php(165): IPS\Login\Handler\OAuth2\_Google->userProfileName()
#2 /opt/forum/applications/core/modules/front/system/settings.php(64): IPS\core\modules\front\system\_settings->_overview()
#3 /opt/forum/system/Dispatcher/Controller.php(118): IPS\core\modules\front\system\_settings->manage()
#4 /opt/forum/applications/core/modules/front/system/settings.php(49): IPS\Dispatcher\_Controller->execute()
#5 /opt/forum/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\front\system\_settings->execute()
#6 /opt/forum/index.php(13): IPS\_Dispatcher->run()
#7 {main}

I've not looked into why this is happening, but it seems to be happening fairly frequently. I'm on 4.7.0, but this code doesn't seem to have changed in 4.7.1.

[Marc Stridgen]

You have quite a few modified files there. One of which is the login handler for google which is showing up there. Please revert these to their defaults and test in the first instance

[Colonel_mortis]

All uncaught exceptions are reported to IPS automatically (when opted in), right? Is it really too much to ask that when I report an exception, you check whether that exception is widespread?

The problem here is not the changes that I made to this code (which were put in place to address other similar issues, although I don't know if they are still relevant). As far as I can tell, Google made a breaking change to their API to cause this. I'll add it to the list of modifications that I make to IPS files.

[Randy Calvert]

14 minutes ago, Colonel_mortis said:

 

All uncaught exceptions are reported to IPS automatically (when opted in), right?

 

No. It logs high level statistics not every single exception. It monitors things like if you use features like elasticsearch or how many sites have marketplace resources, or if SSL is enabled.  Think of it more as trending data such as common errors.   It does not report every single exception, etc. That could result in HUGE amounts of storage being used. 

it’s on you to monitor your community. 🙂 

Edited August 20, 2022 by Randy Calvert

[Colonel_mortis]

Just now, Randy Calvert said:

No. It logs high level statistics not every single exception. Things like if you use features like elasticsearch or how many sites have marketplace resources, or if SSL is enabled. It does not report every single exception, etc. That could result in HUGE amounts of storage being used. 

it’s on you to monitor your community. 🙂 

It does also report exceptions 🙂 

	/**
	 * Should a given exception be reported to IPS? Filter out 3rd party etc.
	 *
	 * @param	\Throwable	$exception	The exception
	 * @return	void
	 */
	final public static function reportExceptionToIPS( $exception )
	{
		$response = \IPS\Http\Url::external('https://invisionpowerdiagnostics.com')->request()->post( array(
			'version'	=> \IPS\Application::getAvailableVersion('core'),
			'class'		=> \get_class( $exception ),
			'message'	=> $exception->getMessage(),
			'code'		=> $exception->getCode(),
			'file'		=> str_replace( \IPS\ROOT_PATH, '', $exception->getFile() ),
			'line'		=> $exception->getLine(),
			'backtrace'	=> str_replace( \IPS\ROOT_PATH, '', $exception->getTraceAsString() )
		) );
		
		if ( $response->httpResponseCode == 410 )
		{
			\IPS\Settings::i()->changeValues( array( 'diagnostics_reporting' => 0 ) );
		}
	}

[Randy Calvert]

Again from a high level statistical level. It’s not meant to be a proactive debug and engage tool. 🙂 

That would most likely come with a HUGE price tag. If people are complaining about the cost of cloud hosting, just imagine the cost it would take to provide proactive eyes on glass monitoring. 

Edited August 20, 2022 by Randy Calvert

[Colonel_mortis]

7 hours ago, Randy Calvert said:

Again from a high level statistical level. It’s not meant to be a proactive debug and engage tool. 🙂 

That would most likely come with a HUGE price tag. If people are complaining about the cost of cloud hosting, just imagine the cost it would take to provide proactive eyes on glass monitoring. 

I'm not proposing that they proactively monitor all exceptions reported by everyone (although I do think that with the right architecture (clearly they should not look at every single individual log) it would be feasible with minimal overhead, and fairly valuable).

All I am asking for here is that when someone reports a bug relating to an uncaught exception, IPS support use the logs to see whether it's a widespread issue or just isolated to the reporter, and handle it accordingly.

If the logs aren't being used for proactive or reactive error investigation, I'm struggling to see why they bother to collect them at all.

[Marc Stridgen]

Please understand that techs responding to support queries may not be developers  themselves. We would not confirm through code or logs if we have seen items such as that, as they may well be unrelated in nature. When there are known problems in areas however, we would see them in our bug reports.

The IPS Diagnostics are for general patterns, rather than specific instances. For example, if we see x happening repeatedly in y area on z occasions, we may decide as a company that area needs to be looked into at a higher level than simply fixing one bug. 

I understand your are a developer yourself, and I understand the frustration entirely. However we simply cant go through peoples individual code. You are running custom code in that area, and also not running the latest release. I understand you have checked code differences between 4.7.0 and 4.7.1, but we dont support altered code as per our support terms, and while we of course will make common sense exceptions for this (and Im sure you will agree we have in your case on many occasions), there was no information given there. Just that its broken. And we need to follow the support procedure on this.