Visual run can break scheduled jobs

[cg2v]

When scheduled jobs run (and assuming the visual run feature has not been used since the web process was last restarted), the rails process forks before the module is loaded, so on each run:

• The action code is always loaded, because the action path has not previously been require'd
• The Updater object is not defined before the action code is loaded, so there are no issues with redefining it.

Once the Visual Run feature is used to execute a scheduled job action, neither of those things is true, because the require (and Updater.update) are run in the normal rails handler process. Furthermore, this affects future background invocations forked from the same process!

The lack-of-forking has two significant effects

• The instructor action code is not reloaded on future runs (require is "require once"), so edits of the action script are ignored until the rails process restarts
• The type of Updater cannot change (some scripts declare Updater to be a Class, others make it a Module. rails allows classes and modules to be redefined, but it does not allow you to define a Module when a Class of the same name exists or vice versa.)

[cg2v]

In production currently, I am hacking around this issue.

I am solving the reload problem by using load instead of require I am "solving" the redefinition problem by deleting the Updater constant from the namespace (using Object.send(:remove_const, :Updater))

It would probably be better if we could still isolate the action script by forking and returning the data through a pipe (or some other communication mechanism), or by finding a better isolation system for the scheduler system

[damianhxy]

From what I see, the only purpose of not forking is to easily print error messages using @log.

In that case, it probably suffices to pass @log from child to parent using one of the approaches described here: https://stackoverflow.com/questions/1076257/returning-data-from-forked-processes