Slack plugin sends duplicate notifications for the same Log__c (missing SlackNotificationDate__c check)

[GregoriSoria]

Package Edition of Nebula Logger

Unlocked Package (Slack plugin, 04t5Y0000015oTT)

Package Version of Nebula Logger

v1.5.4.1 (Slack plugin) / v4.18.3.3 (core)

New Bug Summary

SlackLoggerPlugin.sendAsyncSlackNotifications() re-enqueues a Slack notification for a Log__c record that has already been sent, because it only checks SendSlackNotification__c and never checks whether SlackNotificationDate__c is already populated.

Root cause / reproduction

1. Logger.warn(...) / Logger.error(...) + Logger.saveLog() creates a Log__c record with SendSlackNotification__c = true (set by flagLogsForSlackNotification() on BEFORE_INSERT).
2. AFTER_INSERT calls sendAsyncSlackNotifications(), which enqueues a SlackLoggerPlugin queueable job (Job A).
3. Job A's execute(QueueableContext) sends the Slack notification, sets log.SlackNotificationDate__c = System.now(), and calls update sentLogs; (https://github.com/jongpie/NebulaLogger/blob/main/nebula-logger/plugins/slack/plugin/slack/classes/SlackLoggerPlugin.cls#L118).
4. That update re-fires the Log__c trigger, so execute(LoggerPlugin__mdt, LoggerTriggerableContext) runs again with AFTER_UPDATE, calling sendAsyncSlackNotifications() a second time.
5. sendAsyncSlackNotifications() only checks log.SendSlackNotification__c (https://github.com/jongpie/NebulaLogger/blob/main/nebula-logger/plugins/slack/plugin/slack/classes/SlackLoggerPlugin.cls#L138), which is still true (nothing ever clears it), so it enqueues another job (Job B) for the same, already-sent log.
6. Job B sends a duplicate Slack notification, updates the record again, and the cycle repeats until Salesforce's queueable chain-depth limit stops it.

In our org this produced 3 duplicate Slack messages for a single Logger.warn() + Logger.error() call, confirmed via AsyncApexJob (3 separate SlackLoggerPlugin queueable executions, ~1-2 seconds apart, for one Log__c record).

Suggested fix

In sendAsyncSlackNotifications(), also require log.SlackNotificationDate__c == null before adding the log to logsToSend:

private void sendAsyncSlackNotifications() {
  List<Log__c> logsToSend = new List<Log__c>();
  for (Log__c log : this.logs) {
    if (log.SendSlackNotification__c && log.SlackNotificationDate__c == null) {
      logsToSend.add(log);
    }
  }
  ...
}

We applied this exact change locally and confirmed it resolves the issue (1 queueable execution / 1 Slack message per log, instead of 3). Happy to open a PR with this fix if useful.

[jongpie]

Hi @GregoriSoria thanks for reporting this! I haven't noticed this issue before, but this seems like an easy enough fix.

I have a few other Slack-related changes that I need to work on (hopefully this week), I can include this bugfix along with my other changes (but thank you for offering to open a PR!!).