feat: add controllable posthog #845
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to 230f5b3 in 2 minutes and 21 seconds. Click for details.
- Reviewed
320lines of code in12files - Skipped
1files when reviewing. - Skipped posting
9draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. docker-compose-full.yml:108
- Draft comment:
New telemetry env variable added. Ensure that NEXT_PUBLIC_ENABLE_TELEMETRY is documented and configured in your deployment settings. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to ensure that a new environment variable is documented and configured. This falls under the category of asking the author to ensure something is done, which is against the rules.
2. docker-compose-local-build.yml:104
- Draft comment:
New telemetry variable is included. Confirm that NEXT_PUBLIC_ENABLE_TELEMETRY is properly set for local builds and documented. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to confirm that a new telemetry variable is properly set and documented. This falls under asking the author to ensure something is done, which is against the rules.
3. docker-compose.yml:67
- Draft comment:
Telemetry variable NEXT_PUBLIC_ENABLE_TELEMETRY is now passed. Ensure that deployment docs mention this configuration. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to ensure that deployment documentation is updated to mention a new configuration variable. This falls under the category of asking the author to ensure something is done, which is against the rules.
4. frontend/app/posthog-identifier.tsx:18
- Draft comment:
User identification now gated by Feature.POSTHOG_IDENTIFY. This design helps restrict user data to production-only telemetry. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
5. frontend/app/posthog-pageview.tsx:16
- Draft comment:
Pageview tracking uses Feature.POSTHOG while identification uses POSTHOG_IDENTIFY elsewhere. This intentional separation allows telemetry events in non‐production if needed. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
6. frontend/components/evaluations/evaluations.tsx:170
- Draft comment:
User identification in evaluations is correctly gated by Feature.POSTHOG_IDENTIFY. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
7. frontend/components/traces/traces.tsx:55
- Draft comment:
Identification for traces is controlled by Feature.POSTHOG_IDENTIFY, which is consistent with other areas. Good design. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
8. frontend/components/user/avatar-menu.tsx:34
- Draft comment:
posthog.reset() is invoked when Feature.POSTHOG is enabled. If reset should align with production identification, consider using Feature.POSTHOG_IDENTIFY for consistency. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment is speculative - it suggests using a different feature flag but doesn't provide clear evidence why this would be better. We don't have context about Feature.POSTHOG_IDENTIFY or how production identification works. The current code's use of Feature.POSTHOG seems logical since it's about general PostHog telemetry functionality. I might be missing important context about how PostHog identification works in production. There could be a legitimate consistency concern here. Without clear evidence that Feature.POSTHOG_IDENTIFY is the correct flag to use, or that there's an actual problem with using Feature.POSTHOG, this comment is too speculative. Delete this comment as it makes a speculative suggestion without strong evidence that there's an actual problem with the current approach.
9. frontend/lib/features/features.ts:60
- Draft comment:
New feature flags (POSTHOG_IDENTIFY and POSTHOG_SESSION_RECORDING) are added. Consider adding inline comments clarifying the intended differences between POSTHOG and POSTHOG_IDENTIFY. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While there are clear implementation differences between these flags, the code itself is quite self-explanatory through the environment variable names. The suggestion to add comments feels like it would just be repeating what's already clear from the code. Additionally, comments about documentation tend to be subjective and not critical for code functionality. The implementation differences might not be immediately obvious to new developers, and documentation could help explain the "why" rather than just the "what". The environment variable names (ENABLE_TELEMETRY vs ENABLE_PRODUCTION_TELEMETRY) already clearly communicate the intent, and the implementation differences are simple enough to understand from the code. This comment should be deleted as it suggests adding documentation that would largely duplicate what's already clear from the code itself.
Workflow ID: wflow_b78ltkWiDXtCVWah
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
dinmukhamedm
previously approved these changes
Sep 11, 2025
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed e552ada in 1 minute and 45 seconds. Click for details.
- Reviewed
84lines of code in4files - Skipped
1files when reviewing. - Skipped posting
4draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. frontend/app/providers.tsx:13
- Draft comment:
Nice improvement using Partial instead of any. Consider listing all required config properties explicitly to enforce stricter type safety in future changes. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
2. frontend/components/traces/trace-view/index.tsx:451
- Draft comment:
Avoid empty catch blocks. Even for localStorage operations, consider logging the error to aid debugging if something goes wrong. - Reason this comment was not posted:
Comment was on unchanged code.
3. frontend/components/user/avatar-menu.tsx:32
- Draft comment:
The previous version checked if telemetry (PostHog) was enabled before calling posthog.reset(). Removing that check might cause unintended calls when telemetry is disabled. Confirm if this change is intentional. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment asks for confirmation of intention, which violates our rules. Additionally, PostHog is a telemetry/analytics library - calling reset() on it when it's disabled is likely harmless since the library would handle that case gracefully. The change simplifies the code by removing a complex condition. This seems like an intentional cleanup. I could be wrong about PostHog's behavior when disabled - maybe it throws errors? Also, removing feature flags might indicate broader architectural changes I'm not aware of. Analytics libraries typically handle disabled states gracefully. Even if there were issues, they would be caught in testing. The comment also violates our rule about asking for confirmation. Delete the comment. It asks for confirmation of intention and the change appears to be a deliberate simplification with low risk.
4. frontend/instrumentation.ts:12
- Draft comment:
Consider using a structured logging method (or logger library) instead of console.log for telemetry status messages in production environments. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
Workflow ID: wflow_xkYGfp4HX4YFvdHv
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed eacd48e in 2 minutes and 3 seconds. Click for details.
- Reviewed
127lines of code in5files - Skipped
0files when reviewing. - Skipped posting
3draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. frontend/app/project/[projectId]/layout.tsx:111
- Draft comment:
Duplicate posthog.identify calls: a direct call (lines 111-116) and a client-side call via PostHogIdentifier (line 129) are both used. Consider consolidating to avoid redundant identification. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
2. frontend/app/projects/page.tsx:48
- Draft comment:
Duplicate posthog.identify calls: both a direct invocation (lines 48-53) and a PostHogIdentifier component (line 63) are used. Consider unifying the identification logic to prevent redundancy. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. frontend/app/layout.tsx:44
- Draft comment:
Different feature flags (Feature.POSTHOG for page views versus Feature.POSTHOG_IDENTIFY for user identification) are used; ensure that this separation is intentional and documented. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The comment is speculative and asks for verification/documentation without clear evidence of a problem. It's discussing potential relationships between feature flags that aren't even visible in this file. We can't verify if there's actually an issue without seeing other files. Maybe there is a legitimate architectural concern about feature flag organization that should be addressed. Maybe POSTHOG_IDENTIFY exists in other files and this separation does need documentation. Even if there is a broader architectural concern, this comment is speculative and asks for verification without showing clear evidence of a problem in the changed code. The comment should be deleted as it violates multiple rules: it asks for verification/documentation, makes speculative claims, and requires context from other files that we can't see.
Workflow ID: wflow_uTTbJYN6kFHbgkjc
You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.
dinmukhamedm
approved these changes
Sep 12, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Important
Add controllable PostHog telemetry with feature flags and environment variables across Docker and frontend components.
NEXT_PUBLIC_ENABLE_TELEMETRYtodocker-compose-full.yml,docker-compose-local-build.yml, anddocker-compose.yml.POSTHOG_IDENTIFYandPOSTHOG_SESSION_RECORDINGtoFeatureenum infeatures.ts.isFeatureEnabled()infeatures.tsto checkNEXT_PUBLIC_ENABLE_TELEMETRYandNEXT_PUBLIC_ENABLE_PRODUCTION_TELEMETRY.RootLayoutinlayout.tsxto conditionally renderPostHogPageViewbased onisFeatureEnabled(Feature.POSTHOG).PostHogIdentifierandPostHogPageViewcomponents to acceptisEnabledprop.ProjectIdLayoutandProjectsPageto conditionally callposthog.identify()based onisFeatureEnabled(Feature.POSTHOG_IDENTIFY).providers.tsxto initialize PostHog only if telemetry is enabled.instrumentation.tsto notify when telemetry is enabled.trace-view/index.tsxandavatar-menu.tsx.This description was created by
for eacd48e. You can customize this summary. It will automatically update as commits are pushed.