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

feat(cdp): add uniqueness constraint for hog functions #28074

Conversation

meikelmosby
Copy link
Contributor

Problem

Currently we can have multiple transformations for the same team having the same execution_order which would make sorting and function execution non deterministic.

Changes

  • added uniqueness constraint on type (e.g. transformation), teamId (e.g. team2) and execution_order (e.g. 1)
  • multiple functions with execution_order null can exist

👉 Stay up-to-date with PostHog coding conventions for a smoother review.

Does this work well for both Cloud and self-hosted?

How did you test this code?

  • added test

@meikelmosby meikelmosby requested review from benjackwhite and a team January 30, 2025 08:47
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

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

PR Summary

Added a uniqueness constraint for hog functions to ensure deterministic execution order within teams, along with comprehensive test coverage.

  • Added constraint in /posthog/migrations/0557_unique_execution_order_per_team_and_type.py enforcing unique execution_order per team and function type
  • Added test in hog-transformer.service.test.ts verifying duplicate execution orders are rejected with appropriate error
  • Added test validating that functions with null execution_order can coexist and execute last
  • Added test confirming functions execute in correct sequential order based on execution_order values

3 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile

("posthog", "0556_add_execution_order_to_hog_functions"),
]

operations = [
Copy link
Contributor

Choose a reason for hiding this comment

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

Not sure I agree with this tbh. Can we do this after we have actually implemented the ordering logic? Feels like there could be a lot of gotchas otherwise

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sure i'll just leave it open for now. i'm speccing out the changes i need to do for the api and not having duplicated execution_orders was one of the concerns in the spec.

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.

2 participants