Thanks to visit codestin.com
Credit goes to github.com

Skip to content

chore: improve testing of notifications in coderd tests #15481

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

Open
johnstcn opened this issue Nov 12, 2024 · 1 comment
Open

chore: improve testing of notifications in coderd tests #15481

johnstcn opened this issue Nov 12, 2024 · 1 comment
Labels
bug risk Prone to bugs s4 Internal bugs (e.g. test flakes), extreme edge cases, and bug risks

Comments

@johnstcn
Copy link
Member

johnstcn commented Nov 12, 2024

Problem

Right now, coderdtest uses a fake notifications enqueuer implementation that simply stores an internal list of enqueued notification messages.
The 'real' implementation actually stores enqueued notification messages in the database.
End result: integration tests end up not checking dbauthz RBAC.
This is partially addressed in #15478 but the actual implemention is not 100% in line with reality.

Proposed solution

Our tests in coderd should use the 'real' notifications.StoreEnqueuer, and enqueued notifications should be stored in the configured database.Store used by the tests.

However, there are some ergonomics considerations to be considered here, as tests will generally want to:

  • Perform some action
  • Wait for a notification to be enqueued asynchronously
  • Perform assertions on the notification

Right now, we would need to resort to polling in order to accomplish this.

An option is to place a thin wrapper around notifications.StoreEnqueuer that exposes the following methods to tests:

  • Wait for a notification to be enqueued successfully
  • Fetch all enqueued notifications
  • Clear all enqueued notifications

cc @dannykopping

@johnstcn
Copy link
Member Author

I took a stab at this in #17449 but this approach means we will need to impelement dbmem.EnqueueNotificationMessageNoLock() to avoid re-entrant locks. I think a better approach would be to phase out the usage of FakeEnqueuer() entirely in favour of a mock where applicable, and default to the real deal.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug risk Prone to bugs s4 Internal bugs (e.g. test flakes), extreme edge cases, and bug risks
Projects
None yet
Development

No branches or pull requests

1 participant