1

I've created a platform event called Review_Event__e in my sandbox, I have a apex class that publishes an event, the debug logs the event was successfully committed but if I monitor Workbench Streaming events no events are shown.

I've also created an Apex trigger which fires when a new event is sent, using debug logs I can see that trigger is never fired so I don't think it's something to do with Workbench.

Code to fire event:

Review_Event__e event = new Review_Event__e();
event.EventName__c = 'test';

Database.SaveResult results = EventBus.publish(event);

// Inspect publishing result for each event
if (results.isSuccess()) {
    System.debug('Successfully published event.');
} else {
    for(Database.Error err : results.getErrors()) {
        System.debug('Error returned: ' +
                    err.getStatusCode() +
                    ' - ' +
                    err.getMessage());
    }
}  

I've looked through some other posts and someone has claimed deleting the Platform event object and recreating resolves the issue, I have tried this without success.

Edit: I have added the debug trace on the Automated Process User.

Second Edit: Looking deeper into the results debug I get this:

getErrors=(Database.Error[getFields=();getMessage=7184d1f5-f8a7-40ca-8788-5888ec2333a1;getStatusCode=OPERATION_ENQUEUED;]);getId=e01xx0000000001AAA;isSuccess=true;

Could the event be stuck in a queue?

Third edit: Included Apex trigger

trigger Review_EventTrigger on Review_Event__e (after insert) {

    System.debug('New events fired!');
    System.debug(trigger.new);
    List<Case> cases = new List<Case>();    

    // Iterate through each notification.
    for (Review_Event__e event : Trigger.New) {
            Case cs = new Case();
            cs.Priority = 'High';
            cs.Subject = 'Review';
            cases.add(cs);
   }

    // Insert all cases corresponding to events received.
    insert cases;

}
  • 1
    Event object types end with "__e" not "__c". Are you sure you provided the correct code? – Phil W Jan 31 at 14:53
  • 1
    Regarding the logs, how did you set up the debug trace? As far as I know, platform event triggers are run as the "Automated Process User", so you'd need to set up a log for that "user" to be able to determine whether or not the trigger is being run. – Derek F Jan 31 at 14:55
  • Yes, trigger-based platform event consumers are executed as the "Automated Process" user (sometimes shown as "Process, Automated" in the UI) and you do have to set up a debug trace for that "user" to see the execution logs. – Phil W Jan 31 at 14:58
  • @PhilW Sorry the code was wrong, I updated it. Same issue. – Deployment Failure Jan 31 at 15:02
  • @DerekF Yep I'm aware of this, I was tracing the automated user. – Deployment Failure Jan 31 at 15:02
1

This isn't a complete answer, because it doesn't solve your issue. But I wanted to explain what you're seeing with that error message.

Even though getErrors returns an error, that "error" is technically a success, as you can see in the presence of an id, and the isSuccess flag being true. I ran into this issue through the REST/SOAP API when an external partner was trying to connect with our org. Rather than inspect the success status, the connector was checking for the presence of an error, and failing the successful integration because it was non-empty.

According to my time with Salesforce support, it is correct behavior for all successful platform event publications to return an error (...?!), with a boolean success status that connections should check. The claim was that the uuid of the platform event (e.g. 232fd30e-0a71-42bd-a97b-be0e329b2ded) needed to be returned to clients after insert, but because there is a chance the processing of a platform event may yield an error, this information is returned in the errors array that normal SObjects use to represent actual, definite errors. I personally think that's a little silly, since no one who understands publish/subscribe would expect the publisher to know if a subscriber had an error; I think the real reason is that they needed a way to return information without giving platform events a different API schema than normal SObjects.

Here is the documentation they gave me however, verifying that the presence of an error does in fact represent success:

"After the platform event message is published, the REST response looks like this output. Headers are deleted for brevity."

HTTP/1.1 201 Created 

{
  "id" : "e01xx0000000001AAA",
  "success" : true,
  "errors" : [ {
    "statusCode" : "OPERATION_ENQUEUED",
    "message" : "232fd30e-0a71-42bd-a97b-be0e329b2ded",
    "fields" : [ ]
  } ]
}

https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_events_publish_api.htm

Concerning what's actually wrong with your code, it looks right to me. The only thing I do differently is to always publish my events in a bulkified manner (using a List), since it counts against DML limits. But that shouldn't prevent your event from publishing.

Some things to look at:

  • Check if the event is configured to publish immediately, or after the transaction commits. If the latter, is it possible that the transaction which creates the platform event is failing, and/or returning to a previous save point?
  • Assuming that the transaction isn't being reverted, I would focus my debugging effort on the listeners (workbench and the trigger). You're getting an id back here, which tells me that it's successfully being published. So unless there's a bug in the EventBus, or a way to configure the bus to not publish provided events (which I haven't heard of), then it's the listeners that are failing, and/or failing to log.
  • If you're logging as Anonymous User, make sure that the trigger listener you set up is still set up. I assume you didn't remove it, but just to be sure, nothing will be logged under that user if an Apex trigger isn't currently listening to that event. Note: process builder listeners log under the user who published the platform event.
  • Just to be safe, I would publish an event manually through the developer console until you can get the listeners to acknowledge receipt. This just cuts out any hidden problems on the publishing end.

I know that doesn't give a definitive answer, but I hope it helps. I love platform events, but they can be a little difficult to debug, since you can't always view the data easily through the UI. If you post the trigger handler, we can take a look at that side as well.

  • I see you added the apex trigger listener, thanks! As a next step, you might try removing everything except the System.debug lines, to simplify it as far as possible until we can get some debug logs. – Nathanael Schmolze Jan 31 at 16:43
  • 1
    So the events are indeed being published, I verified using the EMP Connector. – Deployment Failure Jan 31 at 17:00
  • 1
    Well, if you can't get the debug logging to work off of the trigger, you might remove everything from the trigger, and add a single line: insert new Account ( Name = 'Test Review_Event__e' ). Salesforce debug logging has a lot of complexity around it, so creating an account might be less complex than logging under anonymous user. For me, I would be trying to make each piece of this as simple as possible -- publish the event through dev console, listen from a trigger with one line to log/store the result. If in its simplest form I can't get it to work, then reach out to SF support – Nathanael Schmolze Jan 31 at 17:01
  • 1
    One way to test this without the need for logs is to actually insert some object into the database then look see if that happened. Note that platform events are processed even if the request during which they are published gets rolled back due to error. Also note that the trigger runs as user "Automated Process" so if you add objects into the database that can have an Owner, you should ensure that the Owner gets explicitly set to something more appropriate. This can be really important if you have ownership-related sharing rules and role hierarchies. – Phil W Jan 31 at 17:01
  • 1
    Hah -- Phil and I thinking the same thing ;-) – Nathanael Schmolze Jan 31 at 17:02

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.