Skip to content
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

Conversation

lsparlin
Copy link
Contributor

@lsparlin lsparlin commented Oct 8, 2021

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • Optimization
  • Documentation Update

Description

  • Fix: This feature was already implemented (Remove notifications when mentions are deleted)
    • Small change to make removing of notifications testable
    • Use notifiable_type and notifiable_ids instead of trying to fetch collection that has already been destroyed

Related Tickets & Documents

Closes #13735

QA Instructions, Screenshots, Recordings

  • Comment on an article, mentioning a user
  • Observe notification in mentioned user's notifications
  • Edit comment, removing mention
  • Observe notification removed in user's notifications

UI accessibility concerns?

Added/updated tests?

  • Yes
  • No, and this is why: please replace this line with details on why tests
    have not been included
  • I need help with writing tests

[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.

  • I've updated the Developer Docs or
    Storybook (for Crayons components)
  • This PR changes the Forem platform and our documentation needs to be
    updated. I have filled out the
    Changes Requested
    issue template so Community Success can help update the Admin Docs
    appropriately.
  • I've updated the README or added inline documentation
  • I've added an entry to
    CHANGELOG.md
  • I will share this change in a Changelog
    or in a forem.dev post
  • I will share this change internally with the appropriate teams
  • I'm not sure how best to communicate this change and need help
  • This change does not need to be communicated, and this is why not: please
    replace this line with details on why this change doesn't need to be
    shared

@pr-triage pr-triage bot added the PR: unreviewed bot applied label for PR's with no review label Oct 8, 2021
@github-actions
Copy link
Contributor

github-actions bot commented Oct 8, 2021

Thank you for opening this PR! We appreciate you!

For all pull requests coming from third-party forks we will need to
review the PR before we can process it through our CI pipelines.

A Forem Team member will review this contribution and get back to
you as soon as possible!

@rhymes rhymes requested a review from citizen428 October 8, 2021 10:25
@@ -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?
Copy link
Contributor

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Contributor

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.

spec/services/mentions/create_all_spec.rb Outdated Show resolved Hide resolved
citizen428
citizen428 previously approved these changes Oct 13, 2021
@pr-triage pr-triage bot added PR: partially-approved bot applied label for PR's where a single reviewer approves changes and removed PR: unreviewed bot applied label for PR's with no review labels Oct 13, 2021
@citizen428 citizen428 dismissed their stale review October 13, 2021 03:57

Approved too early.

@pr-triage pr-triage bot added PR: unreviewed bot applied label for PR's with no review and removed PR: partially-approved bot applied label for PR's where a single reviewer approves changes labels Oct 13, 2021
@citizen428
Copy link
Contributor

Can you please have a look at the failing specs?

@lsparlin
Copy link
Contributor Author

lsparlin commented Oct 13, 2021

@citizen428 In resolving the failing spec, I figured out how to make this test work without the environment check 😄

TIL: call Sidekiq::Worker.drain_all if jobs are queued that need to run before making assertions

@lsparlin
Copy link
Contributor Author

Not sure why the E2E Seeded CI task is failing...

@citizen428
Copy link
Contributor

Not sure why the E2E Seeded CI task is failing...

@lsparlin Some of our E2E tests can be a bit flaky. I re-ran them for you, we're good to go now. Thanks!

@pr-triage pr-triage bot added PR: partially-approved bot applied label for PR's where a single reviewer approves changes and removed PR: unreviewed bot applied label for PR's with no review labels Oct 14, 2021
@pr-triage pr-triage bot added PR: reviewed-approved bot applied label for PR's where reviewer approves changes and removed PR: partially-approved bot applied label for PR's where a single reviewer approves changes labels Oct 14, 2021
@juliannatetreault juliannatetreault merged commit ff5a94d into forem:main Oct 14, 2021
@pr-triage pr-triage bot added PR: merged bot applied label for PR's that are merged and removed PR: reviewed-approved bot applied label for PR's where reviewer approves changes labels Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
PR: merged bot applied label for PR's that are merged
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mention notifications should be deleted if mentions are removed
4 participants