[ADVAPP-1726]: Issues with notifying Users of subscription created for them

[krlmrr]

Ticket(s) or GitHub Issue

• https://canyongbs.atlassian.net/browse/ADVAPP-1726

Technical Description

• Add an if/return if the subscribable is null.

Any deployment steps required?

• No

Are any Feature Flags and/or Data Migrations that can eventually be removed Added?

• No

---

Before contributing and submitting this PR, make sure you have Read, agree, and are compliant with the contributing guidelines.

[Orrison]

Though this would prevent the error from being thrown, this does nothing to resolve the issue at play here.

For some reason, the $subscribable is null when this is being run.

This Listener is fired when a Subscription is created for a Subscribable (Student or Prospect) and is queued.

Typically when you encounter things like this, it is a dispatch / database transaction race condition.
i.e. this is getting dispatched and then processed by a worker, before the code that created the Student or Prospect finishes and commits the transaction, saving the details to the database.

Please try and find the root of this issue and remove the current code which would just cover up it happening.
I would trace back from where this listener, to the event, to see where it is fired, AND/OR look to see if events/listeners have a way to ensure they only dispatch after DB transactions in the lifecycle commit, I think Laravel recently added a lot of helpers and interfaces for that.

[Orrison]

I don't think this is correct. The interface is supposed to go onto the Listener not the Event I think: https://laravel.com/docs/12.x/events#queued-event-listeners-and-database-transactions

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud