New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix notifications not deleting because mentions already destroyed #14987
Fix notifications not deleting because mentions already destroyed #14987
Conversation
Thank you for opening this PR! We appreciate you! For all pull requests coming from third-party forks we will need to A Forem Team member will review this contribution and get back to |
app/models/notification.rb
Outdated
@@ -122,7 +122,11 @@ def remove_all_by_action_without_delay(notifiable_ids:, notifiable_type:, action | |||
def remove_all(notifiable_ids:, notifiable_type:) | |||
return unless %w[Article Comment Mention].include?(notifiable_type) && notifiable_ids.present? | |||
|
|||
Notifications::RemoveAllWorker.perform_async(notifiable_ids, notifiable_type) | |||
if Rails.env.production? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super keen on the environment check in the model, to be honest. The model delegates the responsibility of deleting the notifications, so it shouldn't need to know about any specifics related to that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm @citizen428 so would it make more sense to just run Notifications::RemoveAllWorker.perform_async(notifiable_ids, notifiable_type)
each time?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes makes it testable. Are there other precedented approaches to making async jobs testable that I should use as a model?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I just call the job in the spec? I considered doing that, but felt I wouldn't truly be testing this side effect of Mentions::CreateAll#call
with that approach
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lsparlin I understand the intent and am very much on board with that. I'm just not particularly happy with where in the code the environment switch lives. I guess I'd be happier if we e.g. called a synchronous job which in dev just executes and in prod schedules a delayed job. This way you still preserve the black-box testability (i.e. no explicit job calling in the spec) while removing logic from this model.
While this may sound a bit roundabout, it separates concerns in a clearer and cleaner way: jobs know about how they should be run themselves, the calling model doesn't need to concern itself with the specifics. But it may just be better to find a comprehensive strategy for this at a later point, I'm sure we have several similar instances in our codebase that should also be changed.
Can you please have a look at the failing specs? |
@citizen428 In resolving the failing spec, I figured out how to make this test work without the environment check 😄 TIL: call |
Not sure why the |
@lsparlin Some of our E2E tests can be a bit flaky. I re-ran them for you, we're good to go now. Thanks! |
What type of PR is this? (check all applicable)
Description
notifiable_type
andnotifiable_ids
instead of trying to fetch collection that has already been destroyedRelated Tickets & Documents
Closes #13735
QA Instructions, Screenshots, Recordings
UI accessibility concerns?
Added/updated tests?
have not been included
[Forem core team only] How will this change be communicated?
Will this PR introduce a change that impacts Forem members or creators, the
development process, or any of our internal teams? If so, please note how you
will share this change with the people who need to know about it.
Storybook (for Crayons components)
updated. I have filled out the
Changes Requested
issue template so Community Success can help update the Admin Docs
appropriately.
CHANGELOG.md
or in a forem.dev post
replace this line with details on why this change doesn't need to be
shared