Better handling for PHP fatal errors

[macbookandrew]

What would you like to do? When a fatal error is thrown, it would be great to have a bit more context about what file was being processed when the error occured.

Example output when running the PHP7.3 Array Functions task:

>>> Event: Processing paths: app, database/factories, database/seeders, vendor-custom/brilliantpackages/laravel-mysql-spatial/src/Eloquent, config, database/migrations, routes, tests
Fatal error: Cannot declare class Illuminate\Support\Collection, because the name is already in use in /project/vendor/laravel/framework/src/Illuminate/Collections/Collection.php on line 11
Failed to run rector: adopt-new-array-functions: #0 phar:///opt/shift/workbench/src/Tasks/Workbench/AdoptNewArrayFunctions.php(18): Shift\Tasks\Workbench\AdoptNewArrayFunctions->rector('/opt/shift/reso...')
#1 phar:///opt/shift/workbench/workbench.php(95): Shift\Tasks\Workbench\AdoptNewArrayFunctions->perform()
#2 /opt/shift/workbench(9): require('phar:///opt/shi...')
#3 {main}

I’ve searched my codebase for class Collection and ~it’s not coming up~ just found it in _ide_helper.php from this package.

If possible, it would be nice to see the file being processed when the error occurred so I can more easily track it down.

Before/After code snippets Perhaps something like this:

>>> Event: Processing paths: app, database/factories, database/seeders, vendor-custom/brilliantpackages/laravel-mysql-spatial/src/Eloquent, config, database/migrations, routes, tests
Fatal error: Cannot declare class Illuminate\Support\Collection, because the name is already in use in /project/vendor/laravel/framework/src/Illuminate/Collections/Collection.php on line 11
+ File currently being processed: _ide_helper.php
Failed to run rector: adopt-new-array-functions: #0 phar:///opt/shift/workbench/src/Tasks/Workbench/AdoptNewArrayFunctions.php(18): Shift\Tasks\Workbench\AdoptNewArrayFunctions->rector('/opt/shift/reso...')
#1 phar:///opt/shift/workbench/workbench.php(95): Shift\Tasks\Workbench\AdoptNewArrayFunctions->perform()
#2 /opt/shift/workbench(9): require('phar:///opt/shi...')
#3 {main}

[jasonmccreary]

Totally agree. This has all been internal Shift logs, so they're a bit raw. We'll work to clean these up so there's a bit more direction on how you might resolve the issue yourself.

In this case, did removing the _ide_helper.php file resolved the issue?

[macbookandrew]

Unfortunately that didn’t resolve it. I was able to run the same shift on another project and it ran fine so must be something about the specific project, but I haven’t been able to dig any further yet.

All of the generic PHP shifts I tried on that specific project failed with the same error, though the Arrow functions did process and update some files before it failed.

Thanks for Workbench and Shift in general! I didn’t realize Workbench had a bunch of free tasks until the Laravel News podcast mentioned something about it in this week’s episode.

[jasonmccreary]

If you'd be willing to try the same task on the cloud-based Workbench and respond back with the build number, I may be able to help diagnose the issue by reviewing the server logs.

Otherwise, we should be able to patch this in the next week or so.

[macbookandrew]

I can wait for the patch unless it would help you for me to run the same cloud-based task

[jasonmccreary]

The cloud based task might clue me into your problem. But in general, it's not necessary for us to improve the error reporting. So your call. If you run it, feel free to email support with your build number so I can take a look.

[jasonmccreary]

@jessarcher, can you see if we can somehow determine from Rector's output which file it failed to parse and report this back to the app.