Jump to content

OutOfRangeException when switch IN_DEV to true


motomac

Recommended Posts

I have the latest IPS on my local machine in Vagrant. I downloaded the latest IPS DEV Tools, but once I switch IN_DEV to true in my constants.php I get an error page:

OutOfRangeException
No message

/system/Patterns/ActiveRecord.php

    }
        }
        
        /* Load it */
        try
        {
            $row = static::constructLoadQuery( $id, $idField, $extraWhereClause )->first();
        }
        catch ( \UnderflowException $e )
        {
            throw new \OutOfRangeException;
        }
        
        /* If it doesn't exist in the multiton store, set it */
        if( !isset( static::$multitons[ $row[ static::$databasePrefix . static::$databaseColumnId ] ] ) )
        {
            static::$multitons[ $row[ static::$databasePrefix . static::$databaseColumnId ] ] = static::constructFromData( $row );
        }
        if ( isset( static::$multitonMap ) )
        {
            foreach ( static::$databaseIdFields as $field )
            {
                if ( $row[ $field ] )
                {
                    static::$multitonMap[ $field ][ $row[ $field ] ] = $row[ static::$databasePrefix . static::$databaseColumnId ];
                }
            }

All 3rd party plugins and apps are deactivated.

Any ideas?

Link to comment
Share on other sites

(1) I'd recommend manually clearing your datastore folder and/or any other caches just to be safe..

(2) Make sure you're using the latest developer tools package: 

 

I've seen errors like this come up when an out of date devtools package is being used and, for instance, a template has significantly changed.

Link to comment
Share on other sites

On 23.02.2018 at 3:56 AM, Ryan Ashbrook said:

Is there anything in /uploads/logs?

It's empty too.

On 23.02.2018 at 4:15 AM, bfarber said:

(1) I'd recommend manually clearing your datastore folder and/or any other caches just to be safe..

I cleared both as well.

On 23.02.2018 at 4:15 AM, bfarber said:

(2) Make sure you're using the latest developer tools package:

The latest Developer Tools are already installed.

May it be related to the cron jobs? In the ACP I see:

Quote

Maintenance tasks
Routine maintenance tasks are performed as users access the site but it looks like the traffic to your community is not sufficient to run these tasks on time. It is recommended that you set up a cron or a web service to ensure a backlog is not created. If you have recently switched to the 'Run Automatically with Traffic' it may take a short while for the backlog to be cleared and you can ignore this message.

1

I tried to setup cronjobs but the similar message about problems with the scheduler.

If I try to start tasks manually in the ACP I get errors. For example, the task "ScheduledActions":

A configuration or server error has occurred

EX0 Something went wrong. Please try again.

RuntimeException:  (0)
#0 /home/vagrant/Code/site.com/system/Patterns/ActiveRecord.php(120): IPS\_Task::constructFromData(Array)
#1 /home/vagrant/Code/site.com/applications/core/modules/admin/settings/advanced.php(593): IPS\Patterns\_ActiveRecord::load('154')
#2 /home/vagrant/Code/site.com/system/Dispatcher/Controller.php(85): IPS\core\modules\admin\settings\_advanced->runTask()
#3 /home/vagrant/Code/site.com/applications/core/modules/admin/settings/advanced.php(34): IPS\Dispatcher\_Controller->execute()
#4 /home/vagrant/Code/site.com/system/Dispatcher/Dispatcher.php(146): IPS\core\modules\admin\settings\_advanced->execute()
#5 /home/vagrant/Code/site.com/admin/index.php(13): IPS\_Dispatcher->run()
#6 {main}

 

Link to comment
Share on other sites

To clarify for the OP, just because a 3rd party app is disabled, it doesn't disable that applications tasks.  Their tasks still run.  Best practice for app devs is to check to make sure their app is ON before running their task code, but that may or may not have been done.  Also, last I recall there was no way to check and see if a plugin was ON if the task was related to a plugin.

The Plugin and/or App column in the core_tasks table will tell you what app and/or plugin owns the task. 

SQL Toolbox 2018-02-26 10-11-23.png

Link to comment
Share on other sites

@Aiwa, thanks for bringing this up.
IPS 4.x will indeed run all the enabled tasks, no matter if the app or plugin is enabled or not. That  said, the same also appears for Queue Extensions / Background Tasks.

So the best practice for 3rd party developers and their tasks and queue extension is either leave the code if it is going to work even if the application or plugin is disabled (Sometimes it's necessary to do this, that's why we implemented it this way) or to just stop the task exception.

An example can be found in our Commerce-supportAssignedRemindert Tasks where we're running following code:

	public function execute()
	{
		/* Don't send reminders if the application is disabled */
		if( !\IPS\Application::appIsEnabled('nexus') )
		{
			return NULL;
		}

 

Link to comment
Share on other sites

12 hours ago, Aiwa said:

To clarify for the OP, just because a 3rd party app is disabled, it doesn't disable that applications tasks.  Their tasks still run.  Best practice for app devs is to check to make sure their app is ON before running their task code, but that may or may not have been done.  Also, last I recall there was no way to check and see if a plugin was ON if the task was related to a plugin.

The Plugin and/or App column in the core_tasks table will tell you what app and/or plugin owns the task. 

SQL Toolbox 2018-02-26 10-11-23.png

Seriously, that really really really needs to be fixed. For that matter, so should the  app tasks. If you disable an app, the WHOLE THING should be disabled.

Link to comment
Share on other sites

4 hours ago, HeadStand said:

Seriously, that really really really needs to be fixed. For that matter, so should the  app tasks. If you disable an app, the WHOLE THING should be disabled.

Didn’t know that. So your resource is disabled but still working in the underground of the framework? Curious!

Will have to change all my tasks. 

Link to comment
Share on other sites

10 hours ago, HeadStand said:

Seriously, that really really really needs to be fixed. For that matter, so should the  app tasks. If you disable an app, the WHOLE THING should be disabled.

 

5 hours ago, Adriano Faria said:

Didn’t know that. So your resource is disabled but still working in the underground of the framework? Curious!

Will have to change all my tasks. 

Yup, I pushed commits last night to fix this.  It's been a low hanging bug for quite some time.  Thankfully I've only got apps with tasks, so I didn't have to figure that one out.

Link to comment
Share on other sites

14 hours ago, bfarber said:

What application does the task belong to? As @Daniel F said, this doesn't look like a default task from any of our applications.

I have no idea... I uninstalled all other apps and plugins, but I still see these two tasks:

5a963968b5fe5_2018-02-2813_05_19.thumb.png.d08686409a09ffdbd489ba307ca8ff82.png

In the DB:

5a96396c50011_2018-02-2813_01_37.thumb.png.48cf361ce1ba9961d36bb44b256127ec.png

Apparently, it's some... rules app. I don't remember this app. It doesn't exist in the ACP. Should I remove these two rows?

Link to comment
Share on other sites

Hmm... I don't have this app... Maybe I tried it a long time ago, but it's not presented in the ACP at all.

OK, I deleted these two tasks from the DB, but the problem still exists.

The table core_log is still empty, /uploads/logs folder is empty too.

Link to comment
Share on other sites

1 hour ago, motomac said:

Hmm... I don't have this app... Maybe I tried it a long time ago, but it's not presented in the ACP at all.

OK, I deleted these two tasks from the DB, but the problem still exists.

The table core_log is still empty, /uploads/logs folder is empty too.

Could you please run this again https://invisioncommunity.com/forums/topic/443838-outofrangeexception-when-switch-in_dev-to-true/?do=findComment&comment=2731302 to see which task is causing it now.

 

Link to comment
Share on other sites

On 2/26/2018 at 11:02 AM, Daniel F said:

@Aiwa, thanks for bringing this up.
IPS 4.x will indeed run all the enabled tasks, no matter if the app or plugin is enabled or not. That  said, the same also appears for Queue Extensions / Background Tasks.

So the best practice for 3rd party developers and their tasks and queue extension is either leave the code if it is going to work even if the application or plugin is disabled (Sometimes it's necessary to do this, that's why we implemented it this way) or to just stop the task exception.

An example can be found in our Commerce-supportAssignedRemindert Tasks where we're running following code:


	public function execute()
	{
		/* Don't send reminders if the application is disabled */
		if( !\IPS\Application::appIsEnabled('nexus') )
		{
			return NULL;
		}

 

Oh hell no.  

As a client, after reading this post I am horrified that IPS has not built in protection to the system's queue / task system when third-party applications or plugins are disabled.  When a third-party app is disabled, everything from the third-party app should be disabled.  Everything!  That is my expectation as a client, and it's not an unreasonable expectation in any way.

I have easily installed 50+ applications in the past three years since upgrading to 4.0 -- more purchases than I can remember from the Marketplace; public applications from Marketplace developers to help them test; and even private applications to help users test.  I've installed too many plugins to count, and I've always volunteered myself, my time, and my demo board for these tests to Marketplace authors, IPS users, and IPS itself.  And now you're telling me that all of those applications or plugins, even disabled, might have residual tasks still running on my live server?? There is no way in hell I will accept your current answer.   

I feel strongly that IPS needs to take corrective action, if only to protect IPS clients and the core system from third-party apps and plugins.

And while I'm in the middle of burning IPS, I also want to point out: if IPS' official advice is to recommend a best practice to their Marketplace authors, this advice better be a goddamn best practice that is pinned / emailed / featured in a goddamn developer article that you've already posted.  Because if it's not, then IPS has totally failed across the board at protecting the integrity of client systems.

Link to comment
Share on other sites

On 26/02/2018 at 5:02 PM, Daniel F said:

@Aiwa, thanks for bringing this up.
IPS 4.x will indeed run all the enabled tasks, no matter if the app or plugin is enabled or not. That  said, the same also appears for Queue Extensions / Background Tasks.

So the best practice for 3rd party developers and their tasks and queue extension is either leave the code if it is going to work even if the application or plugin is disabled (Sometimes it's necessary to do this, that's why we implemented it this way) or to just stop the task exception.

An example can be found in our Commerce-supportAssignedRemindert Tasks where we're running following code:


	public function execute()
	{
		/* Don't send reminders if the application is disabled */
		if( !\IPS\Application::appIsEnabled('nexus') )
		{
			return NULL;
		}

 

Why not add that to the tasks.txt file so when we generate the file it will be there already?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...