3

Use case:

  • Testmethod that invokes a service with more than 200 Sobjects
  • Service does work on each Sobject and as a side effect, also publishes Platform Events
  • By varying the number of Sobjects, at some point, the testmethod fails with an internal server error (gack) with error code 255731747. No other exception thrown or caught.

What is the cause?

5

Thank goodness we have premier support as within a few hours, I had the stacktrace for the Gack:

Internal Salesforce Error: 493985485-49401 (255731747) (255731747)

SourceClassName: data.api.event.EventConduitDataSourceConnection

SourceMethodName: upsertRows

Subject: Sandbox: Sandbox: Error during SoapOperationRunTests at
data.api.event.EventConduitDataSourceTable.publish(EventConduitDataSourceTable.java:58)

ExtendedMessage: data.api.DataSourceException: Failed to publish events

Thrown: data.api.DataSourceException: Failed to publish events

Cause0: common.exception.ApiException: Event push failed

Cause1: common.api.conduit.PlatformEventPublisher$PublishException: Error publishing 100 platform events

Cause2: common.apex.runtime.impl.ExecutionException: Too many platform events enqueued for this apex test context

Cause3: common.exception.LimitExceededException: Too many platform events enqueued for this apex test context

So, the issue is that Salesforce is not throwing a Limits exception in this case but is instead just abruptly dying. The documentation states the following:

In addition, event allocations don’t apply to test events, which have their own publishing limit of 500 event messages in a test method.

My testmethod was generating in sequence (one transaction):

  • 200 Platform events
  • 3 Platform Events
  • 200 Platform events
  • 3 Platform events (cumulative 406)
  • 100 Platform events this is the stacktrace above; 406 + 100 > 500 KABOOM

So, while subscribing triggers can be presented with up to 2000 platform events, Apex (testmethod) can't generate more than 500 platform events.

My use case was using platform events as a backup mechanism for an incoming mass transaction where #sobjects could be 1...2000. I wanted to verify that CPU Limits would not be exceeded --but ran into the gack and the 500 publishable events in a testmethod. Volume testing of this nature can't be done in testmethods and instead requires execute anonymous, POSTMAN, or some other external client.

UPDATE - This is now a Known Issue - Be sure to mark this as "affects me" if appropriate

UPDATE - Fixed in Spring 19 Patch 4.0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.