Skip to content

feat(nimbus): Send results available notification#14616

Merged
yashikakhurana merged 1 commit intomainfrom
14409
Feb 11, 2026
Merged

feat(nimbus): Send results available notification#14616
yashikakhurana merged 1 commit intomainfrom
14409

Conversation

@yashikakhurana
Copy link
Contributor

Because

  • We want to notify users on slack when the weekly and overall results are available for the experiments

This commit

  • Check whether the results are available, and if available, send the notification
  • Also makes sure to send the alert once per window such as overall and weekly

Fixes #14409

Copy link
Collaborator

@jaredlockhart jaredlockhart left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay looking good, good clear layout, good test coverage, let's give it a shot! thnx @yashikakhurana 🙏 🎉

@yashikakhurana yashikakhurana added this pull request to the merge queue Feb 11, 2026
Merged via the queue into main with commit 05bbe9f Feb 11, 2026
18 checks passed
@yashikakhurana yashikakhurana deleted the 14409 branch February 11, 2026 18:39
jaredlockhart pushed a commit that referenced this pull request Feb 11, 2026
Because

- We want to notify users on slack when the weekly and overall results
are available for the experiments

This commit

- Check whether the results are available, and if available, send the
notification
- Also makes sure to send the alert once per window such as overall and
weekly

Fixes #14409
Comment on lines +816 to +818
class AnalysisWindow(models.TextChoices):
WEEKLY = "weekly", "Weekly"
OVERALL = "overall", "Overall"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we generate this from the existing enum definition (either in schemas or jetstream client?


return False

def has_results_for_window(self, window):
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 getting a little confused about where different results functions like this should go now that some of them are here and others are in the results manager class. For example, here we have has_results_for_window and there we have get_window_results.

This isn't a comment about this particular function, just a question more generally: is the convention that we want all the actual results fetchers and mutators to go in results_manager and all the higher level boolean-type logic to go here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah so, I think once we have the new results page launched I want us to go back through the infrastructure we have now for

  1. Jetstream loading
  2. Transforming into the visualization structure
  3. Storing
  4. Querying

Because we have many layers there that are probably unnecessary and can collapse, but I don't think we have the structure we'll want there in place yet, so yes littering methods like this around probably isn't ideal but I think we'll be able to clean all that up in a post launch cleanup phase.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Alert when daily/weekly/overall Jetstream results become available

3 participants

Comments