Description
An event may generate an error traced in the log with the originating reason, but the displayed message seems incorrect:
2011-11-17 07:15:31 (365) worker.4 worker.4 Connected
2011-11-17 07:15:31 (374) worker.4 worker.4 Processing 0 emails
2011-11-17 07:15:31 (374) worker.4 worker.4 Processing email total: 0, new: 0, deleted: 0, unread: 0
2011-11-17 07:15:31 (397) worker.0 worker.0 WARNING *** WARNING *** EventRecord: getEventTarget() called with invalid record reference: sc_request.d63e4f07299a148044d78d67c8138c5e for event: email_equipment_return, could have been deleted
2011-11-17 07:15:31 (423) worker.4 worker.4 Processed 0 emails
The record is there and is not deleted. There are events that do not have a state of "error" that call to the same record type in the same way.
Steps to Reproduce
- View the events for errors and get the sys_id of the record in the URI field of the event
- Go in to the daily log for the same day of the error and search by the sys_id
- Note the output log which states a record does not exist, when it actually does
Workaround
This message can have different causes.
1/ It can be caused by a temporary impersonation issue. If an impersonation is initiated but then not reversed back to the original impersonator, the user will be stuck in a bad state of impersonation. This can be observed by looking at the user that updated the event. If this is not system and is instead a user that does not have access to the instance record on the event, the event will output this error when processed. However, there is no platform code fix necessary.
2/ It can be due to a domain updated issue as part of processing a specific event.
3/ It can be due to the before insert BR --- wherein we are also passing the current record while invoking gs.eventQueue API -- And the event got picked up for processing before the current record got inserted. In such event, it is recommended to implement the eventQueueScheduled() method to fire the event a few seconds/minute into the future so that we can ensure the record is created first and the event is successfully processed.
4/ It can be genuinely the fact that particular record got deleted.
PS: The 5th parameter for the eventQueue function is not part of the eventQueueScheduled API but this parameter is an override of the queue defined in the event registry and should not impact the functionality.
Related Problem: PRB565663