Organize deployment errors for better signal-to-noise ratio when there are GACKs and failures from failed (transitive) dependencies

[Justin Julicher]

Filter Issues:

When you try to refresh a sandbox with updates from other developers and deploy say 50 files and you have a couple of failures what often happens is that you have all the other files fail with something like:

‌

However, these files haven’t actually failed, and you have to then search through the other 50 lines of results to find the actual issue like:

‌

If would be good if you could either group the ‘Unexpected error occurred’ or filter them out entirely as they are generally rubbish.

edit:

Thinking about this further - I was thinking that possibly flipping the file/error around would give a clearer idea of what is going on?

e.g.

• Dependent class is invalid and needs recompilation: Class A: Unexpected token '.'.

  • Error:(34, 13) force-app\main\default\classes\D.cls
  • Error:(34, 13) force-app\main\default\classes\E.cls

• An unexpected error occurred. Please include this ErrorId if you contact support: 138656565656-22256 (-1684384848)

  • Error:(1, 1) force-app\main\default\classes\F.cls
  • Error:(1, 1) force-app\main\default\classes\G.cls
  • Error:(1, 1) force-app\main\default\classes\H.cls

‌

You could perhaps have a button in the gutter to flip this around (where the show warnings and show info buttons are).

Enhance Issues output and Add Context Menu

So in the filter issues scenario once you have resolved the deployment issue you would want to redeploy the same files. It would be great if you could add a top level branch to this tree to have the deployment info something like:

‌

And then add a context menu to the top level branch to ‘Redeploy Package’. Alternatively you could enable the select and deploy in this dialog (tried that as it works in most places but not this tab :( )

Let me know if that isn’t clear.

‌

thanks

‌

[Scott Wells]

Yeah, I’ve definitely considered trying to organize reported errors into a more usable form, both those resulting from GACKs as in your example and those resulting from transitive failures where sometimes one class fails to compile and every class that depends directly or indirectly on that class also fails resulting in a ton of noise. I definitely think something like that would be incredibly useful. Let me chew on how it might be done a bit and then I’ll see about taking a stab at it.

[Scott Wells]

Implemented for delivery in the next build. It doesn’t thread together all of the details of transitive dependencies, but it does partition reported deployment errors into failures, transitive failures, and unexpected errors/GACKs in both the Problems view:

and the Messages view:

My guess is that such organization of reported errors should go VERY far in allowing users to resolve the root cause issues more quickly.

[Scott Wells]

I also made it so that transitive failures link/resolve to the appropriate file as the deepest transitive dependency in the reported error message, so I think in essence that should address all of the primary concerns.

[Scott Wells]

Delivered in 2.2.6.4.

[Justin Julicher]

Scott that looks fantastic!

Can’t wait to see the result when I next have transitive errors!

‌