5

This question is more a search for advice.

I have been in charge of the building and releasing of a managed package for a couple of iterations now. When creating the first couple of betas we usually get an issue when installing on a dev org to test the package out. Even though we have set the Apex Error Email when I build the beta nothing with any useful information gets sent. All we get is the standard package failure email and it gets sent to the user who is installing the package. Nothing is sent to the creator of the package as specified in the Apex Error Email.

We have no tests that are run on install so the error is from either the post install script, some meta data we added or from a platform bug (as happened when Spring '14 was released)

Is it possible to get any information about the failure without going a couple of rounds with SF support? Does anyone have any general advice on how to debug beta package install/update issues?

Below is the standard email we get sent

Your request to install package "XXXXXX" was unsuccessful. None of the data or setup information in your salesforce.com organization was affected.

If your install continues to fail, contact Salesforce CRM Support through your normal channels and provide the following information.

Organization: XXXXX (XXXXXX)

User: XXXXX (XXXXX)

Package: XXXXX (XXXXX)

Error Number: 1503922217-46640 (1790482155)

Improve this question

1 Answer 1

Reset to default
6

Such error messages represent internal platform failures (or gacks as they are sometimes known) rather than anything in your Apex code, this is why your Apex Exception User is not receiving anything. The underlying reason could be a range of things, a bug in the platform code or an error relating to a feature or incompatability in the org your trying to install into.

From my experience it has mostly be the case of the later, where something in the subscriber org is not set or provisioned or the presence of a earlier release of your package is causing an upgrade issue. The fact is in most cases I've found Salesforce agreeing with me such things should be fed back to the user performing the install at the very least.

The answer at this present moment in time is to raise a case with Salesforce and if it is something they can share directly (e.g. not a true internal failure) they most likely will. The following are the types of reasons I've come across in the past.

  • A package feature dependency is not enabled in the subscriber org, such as Mult-Currency or more recently I've come across a gack where Ideas is not enabled (which is strange because the package in question doesn't have an explicit reference to this feature). Check your dependencies by clicking Show Dependencies button on your Package detail page and review them.
  • A an upgrade issue is preventing install. The simple test for this is to attempt an installation in another org (ideally) or the same org without your package present.
  • It is org specific something in the specific org your installing in is preventing install or upgrade, try a number of other orgs to see if you get the same results.

Hope this helps, you and Salesforce get to the bottom of this quickly, these issues can be a real pain at a very sensitive part of your project cycle!

Improve this answer
2
  • 2
    Thanks Andrew very helpful. I feared that there would be not much more to do than just raise a case and accept the frustration of the 12 hour turn around. I hope SF will make this more transparent in the future to avoid delays in the release cycle I will look at the specific areas you mentioned.
    – Owen Davies
    Jul 17, 2014 at 7:48
  • Your welcome, and yes I'm also pushing Salesforce to make this more transparent, i can say i'm happy things are going in the right direction from what I'm being told.
    – Andrew Fawcett
    Jul 17, 2014 at 8:10

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .