0

I'm trying to debug this recent issue. Code works fine in scratch orgs, but when ran in managed package scheduleBatch seems to never execute. I wonder if there's some throttling going on as we use this mechanism to chain batch jobs (although this happens on very first use of method, not far into chain).

Is there some ways to debug this (can't see our own logs, ugh.)

Edit: adding some screenshots. Note after Next Scheduled Run the CronTrigger.State changes to deleted. No debug log gets generated 🤷‍♂️

enter image description here

enter image description here enter image description here enter image description here

2 Answers 2

1

You can do Troubleshooting in Subscriber Organizations. When you Log In to Subscriber Orgs from a License Management App-enabled org, you can either use the ISV Customer Debugger or you can get ISV-only logs from the Developer Console. You'll need to Request Login Access from a Customer before you can use these features, however.

In general, there is no additional throttling that happens when scheduling jobs, but do be aware that the Execution Governors and Limits restrict an org to 100 scheduled jobs in total (including Scheduled Batchable jobs). Make sure you're not exceeding these limits. You should be able to use a try-catch block to detect when this situation occurs:

try {
  System.scheduleBatch('jobName',new BatchableClass(), minutesFromNow);
} catch(AsyncException e) {
  // Can't schedule job for some reason
} catch(StringException e) {
  // Invalid job name, etc
}
4
  • So this is a fresh dev org, fresh app install. Job succeeds in scheduling, but has no timeframe to execute it... :D
    – dzh
    Commented Jan 25, 2021 at 23:45
  • Dunno why Salesforce limits this Package and subscriber org namespace collision, Details: The installing package namespace and org namespace cannot be the same. - would solve so much debugging problems! Just let us install package under same ns so we can view logs!
    – dzh
    Commented Jan 25, 2021 at 23:48
  • @dzh Because the components would conflict. I agree it's not ideal, but Scratch Orgs are supposed to be how you do this kind of testing. You should still be able to get logs with Login Access, though.
    – sfdcfox
    Commented Jan 26, 2021 at 0:31
  • Worked with my superior to get some logs. Aura logs are fully fledged, however batch apex are still useless as most of it is obfuscated...
    – dzh
    Commented Jan 26, 2021 at 3:21
1

In order to get logs from a subscriber org containing info from your package's Apex you need to make sure you:

  1. Gain login access for your "support" (request login access and have it granted).
  2. Login via your PBO's Subscribers tab.
  3. Create a new User Trace Flags through Setup > Environments > Log > Debug Logs (this must be done using the subscriber login grant), making sure to provide adequate time coverage for your needs and using a "log type" that has debug, fine or better Apex tracing.
  4. Execute the required processing on the subscriber org with whichever user you set up the trace flags for.
  5. Open the Debug Log using the same login as step 2.

As long as you follow these steps appropriately you will be able to get unobfuscated and detailed logs from your package on the subscriber org.

It should be noted that you might be bumping into this issue and I would encourage you and your team mates to upvote it to help get this problem resolved.

7
  • Cherry on top is you can't see debug logs from batch apex, unless you raise a case with Salesforce support.
    – dzh
    Commented Jan 26, 2021 at 8:56
  • @dzh that isn't my experience. You simply need to make sure that the batch apex runs under the same user as you have set up the trace flags for.
    – Phil W
    Commented Jan 26, 2021 at 9:28
  • @dzh please do also note the "issue" link I provided.
    – Phil W
    Commented Jan 26, 2021 at 9:30
  • The issue I observe only between my package API versions. Dunno about your experience, but we've tried to get some logs out todo and we could only see aura side of things. Whenever batch runs it's ENTERING_MANAGED_PKG.
    – dzh
    Commented Jan 26, 2021 at 11:51
  • That implies one of a) you didn't create the user trace flags via the subscriber login user or b) you're not using the correct subscriber login (if you have different packages on different LMOs) or c) you've not set the Debug Levels correctly for Apex. Or perhaps you are trying to debug a 2GP and this behaves differently compared with a 1GP (which is my only experience from the debugging perspective so far).
    – Phil W
    Commented Jan 26, 2021 at 12:21

You must log in to answer this question.

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