From e86dbad6d6a6ecdca458eb527e54dca251e3575f Mon Sep 17 00:00:00 2001 From: Diogo Peralta Cordeiro Date: Sat, 19 Feb 2022 04:47:08 +0000 Subject: [PATCH] [COMPONENT][Notification] Don't explode with understandable duplicate notifications This is common when a duplicate federation request is received --- components/Notification/Notification.php | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/components/Notification/Notification.php b/components/Notification/Notification.php index 58a462a6bc..94b40902b6 100644 --- a/components/Notification/Notification.php +++ b/components/Notification/Notification.php @@ -119,11 +119,17 @@ class Notification extends Component // XXX: Unideal as in failures the rollback will leave behind a false notification, // but most notifications (all) require flushing the objects first // Should be okay as long as implementors bear this in mind - DB::wrapInTransaction(fn () => DB::persist(Entity\Notification::create([ - 'activity_id' => $activity->getId(), - 'target_id' => $target->getId(), - 'reason' => $reason, - ]))); + try { + DB::wrapInTransaction(fn () => DB::persist(Entity\Notification::create([ + 'activity_id' => $activity->getId(), + 'target_id' => $target->getId(), + 'reason' => $reason, + ]))); + } catch (\Exception|\Throwable $e) { + // We do our best not to record duplicated notifications, but it's not insane that can happen + Log::error('It was attempted to record an invalid notification!', [$e]); + } + } FreeNetwork::notify($sender, $activity, $remote_targets, $reason);