-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
wip: support test_ api key #4206
Conversation
Anyone know what this check is failing? It's a python issue that doesn't make sense to me. |
Re @buwilliams,
The check that was failing indicated that there was a typing problem. Python has only limited support for typing, introduced fairly recently (see more details). One of the limitations is that typing is not actually checked when coding (some IDEs might support this) or at runtime. Instead, we use https://github.com/python/mypy to check typing. You can run it yourself locally by doing See 87018fc for details on how the specific typing issue was fixed. |
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.
Added some comments. Also proposing a different UI for the toggle (feel free to challenge / iterate).
- Also worth noting, what happens when you change the filter? Ideally we would reload the graph, table you're viewing.
- Finally, we should also remove the test filters toggle from the UI if the feature flag is enabled.
Here's my proposed UI for this. Feedback @corywatilo too? OutstandingPlease note I think we should also add a global indicator to all pages to be more explicit when you're on test data mode. Something like this, |
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.
Hey! So, I posted the original env separation issue, and I think this implementation may be too narrow. I think it's quite possible we'll want to support more such environments than with just a boolean switch (e.g. selector a la Sentry), so it'd be more flexible if instead of $test_environment: true/false
we used $environment: 'production'/'development'
.
Aaand, that still does not address a key issue that motivates this feature request: users want to get rid of environments with junk data, but that's not possible - events, once ingested, they history forever, because we don't delete CH events yet. With projects that's kind of solved because the data is just inaccessible once the project is deleted, thanks to using team_id
for all filtering.
@Twixes Why does removing the data matter? Filtering removes unwanted results so the effect is the same from a UI perspective. Additionally, if a flag such as test_environment is present, deleting that data becomes trivial. In either case, removing the data seems like a follow-up issue. One that allows users to purge data based on a filter. The reason for having boolean rather than by environment was to aid UX since we can think about production and all others and two distinct things and present a simple UX for it. Otherwise, we'd need to create an additional table where users would be to specify their environments so that we could group them appropriately. Seems to me, if an advanced user wanted to track per environment, they could add this as a regular event property. Something like: |
I've changed the Boolean to a string and renamed it to $environment. Currently, it supports: "production" and "test". Also, I've moved it into a hidden property. Push coming soon. |
Yep, okay, actually removing the data from our disks doesn't matter (that much), but removing it from the user's point of view (meaning just making it completely inaccessible) matters. So it's enough to just always and everywhere filter based on this property. And the environments for a project can be just a Postgres array of strings on the |
I agree with @buwilliams, I think multiple environments could be a more advanced use and to consider for later. In terms of data deletion, I'm torn but leaning towards this is the right approach. Deleting data is a separate thing we need to tackle. @buwilliams perhaps it's useful to add the context on why we decided against separate projects for this ? |
I'm blocked until M1. What I thought was a bug in my code was not. Events are not ingested because we process events by sending them to a job queue on our plugin server. I was misguided because |
To clarify one point, the plugin server definitely does not rely on clickhouse, as we also use the same plugin server for the OSS / non-clickhouse installations. Without explicitly setting |
Solved the issue with the plugin-server by running |
Co-authored-by: Paolo D'Amico <[email protected]>
Changes
test_[apiKey]
which signifies local, test, and staging environmentstest_[apiKey]
sets$environment
totest
$environment
See #3149 for more information
Checklist