chore: add anon telemetry

[srijanpatel]

Important

Add anonymous telemetry using PostHog with options to disable via environment variables, including backend API and frontend integration.

• Telemetry Integration:
  • Added anonymous telemetry using posthog-js in frontend/src/pages/_app.tsx.
  • New API endpoint get_anon_data_status in backend/pyspur/api/key_management.py to check telemetry status.
  • Added getAnonDataStatus function in frontend/src/utils/api.ts to fetch telemetry status.
• Configuration:
  • Updated .env.example to include DISABLE_ANONYMOUS_TELEMETRY setting.
  • Added posthog-js dependency in frontend/package.json.
• CLI and Server:
  • Added telemetry notice in init and serve commands in backend/pyspur/cli/main.py.

^{This description was created by for 837245b. It will automatically update as commits are pushed.}

[ellipsis-dev]

❌ Changes requested. Reviewed everything up to 735de5a in 2 minutes and 41 seconds

More details

• Looked at 287 lines of code in 6 files
• Skipped 2 files when reviewing.
• Skipped posting 13 drafted comments based on config settings.

1. backend/pyspur/api/key_management.py:454

• Draft comment:
  Good use of exception chaining with 'from e' for better debugging.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. frontend/package.json:53

• Draft comment:
  New dependency 'posthog-js' added; verify version compatibility with existing libraries.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

3. backend/pyspur/cli/main.py:120

• Draft comment:
  Telemetry notice in init command is clear. Ensure consistency with similar messaging in serve command.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

4. frontend/src/utils/api.ts:332

• Draft comment:
  getAnonDataStatus is implemented correctly, but ensure error handling aligns with frontend error boundaries.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

5. .env.example:123

• Draft comment:
  Telemetry config is clear, but consider explicitly stating that uncommenting DISABLE_ANONYMOUS_TELEMETRY disables usage data.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

6. backend/pyspur/api/key_management.py:472

• Draft comment:
  The new /anon-data/ endpoint directly returns an env variable status; consider if this endpoint should be secured or require authentication.
• 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 env var being accessed (DISABLE_ANONYMOUS_TELEMETRY) is not sensitive - it's just a boolean flag for whether telemetry is disabled. Unlike other endpoints in this file that access API keys and secrets, exposing this value poses no security risk. The comment seems overly cautious about a non-sensitive configuration value.
  Maybe there's a broader security principle about not exposing any env vars without authentication, regardless of sensitivity? Or maybe this env var could be used for fingerprinting the server configuration?
  The potential risks seem very minor compared to the value of having this simple status check be publicly accessible. This isn't sensitive data that needs protection.
  The comment should be deleted. Authentication is unnecessary for this non-sensitive telemetry configuration flag.

7. frontend/src/pages/_app.tsx:17

• Draft comment:
  Mutable variables (disableTracking and hasDataStatusBeenChecked) used to control rendering won't trigger re-renders. Use useState for proper state management.
• Reason this comment was not posted:
  Marked as duplicate.

8. frontend/src/utils/api.ts:332

• Draft comment:
  getAnonDataStatus looks good; consider adding caching or a fallback value to improve UX in case the API call fails.
• 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 the suggestion to handle errors gracefully is generally good practice, we don't have enough context to know if returning false is the correct fallback behavior. The function is typed to return Promise, so throwing an error may be intentional to let callers handle failures explicitly. Without knowing how this status is used, suggesting a specific fallback value could be dangerous.
  The comment makes assumptions about the desired error handling behavior without understanding the requirements. Returning false could silently hide real issues.
  While error handling is important, we should not suggest specific fallback values without understanding the business requirements and how this status is used.
  The comment should be deleted since it makes assumptions about error handling requirements without sufficient context to know if the suggestion is correct.

9. .env.example:101

• Draft comment:
  In the Google configuration section (lines 101-104), the comment lines start with a double '#' (e.g., "# # This environment variable...") which appears to be a typographical error. Please change them to a single '#' for consistency.
• 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.

10. .env.example:113

• Draft comment:
  In the GitHub configuration section (lines 113-114), the comment lines also start with a double '#' (e.g., "# # This environment variable..."). For consistency, please remove the extra '#' to use a single '#' in these comments.
• 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.

11. .env.example:123

• Draft comment:
  In the Firecrawl configuration section (lines 123-124), the comment lines begin with a double '#' (e.g., "# # This environment variable..."). This appears to be a typographical error; please change them to a single '#' for consistency.
• Reason this comment was not posted:
  Comment was on unchanged code.

12. backend/pyspur/api/key_management.py:407

• Draft comment:
  In the docstring for set_api_key, consider changing 'Add a new environment variable or updates an existing one.' to 'Add a new environment variable or update an existing one.' so that the verb forms are parallel.
• 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%
  While the comment is technically correct about grammar, our rules state we should not make purely informative comments. The docstring is still completely understandable as is, and this is an extremely minor grammatical issue. The rules emphasize focusing on actual code issues rather than documentation tweaks.
  The grammar issue does make the code slightly less professional. Good documentation is part of good code quality.
  However, the rules explicitly state not to make purely informative comments. This is a very minor documentation issue that doesn't impact functionality or maintainability.
  Delete the comment as it's too minor and doesn't highlight a significant code issue requiring change.

13. backend/pyspur/cli/main.py:112

• Draft comment:
  Typo: 'protoype' should be corrected to 'prototype' in the text describing the quick setup step.
• 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.

Workflow ID: wflow_EkiSBigoEsFNKqIj

---

Want Ellipsis to fix these issues? Tag @ellipsis-dev in a comment. You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.

[ellipsis-dev]

👍 Looks good to me! Incremental review on 837245b in 53 seconds

More details

• Looked at 122 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 7 drafted comments based on config settings.

1. backend/pyspur/cli/main.py:162

• Draft comment:
  Good change: duplicate telemetry notice removed. Consider if printing the telemetry note before starting the server fits your UX expectations. (No changes required)
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50%
  None

2. frontend/src/pages/_app.tsx:42

• Draft comment:
  The cleanup function returned from the async initializePostHog isn't hooked into useEffect cleanup. This may leave the event listener attached on unmount.
• 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/src/pages/_app.tsx:58

• Draft comment:
  Conditional rendering now wraps the component with PostHogProvider only if telemetry is active. This is clearer, but ensure that rendering the component without waiting for the telemetry status (if not checked yet) is intended.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

4. backend/pyspur/cli/main.py:162

• Draft comment:
  Consider extracting env var boolean parsing into a helper instead of repeatedly doing os.getenv(...).lower() != "true". This would improve readability and reduce duplication.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50%
  None

5. frontend/src/pages/_app.tsx:40

• Draft comment:
  The cleanup function for the event listener is defined inside the async function but isn’t returned from the useEffect. Since React expects a synchronous cleanup function, this may lead to stale listeners. Consider storing and returning the unsubscribe function directly from useEffect.
• 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.

6. frontend/src/pages/_app.tsx:29

• Draft comment:
  Avoid hardcoding the PostHog API key and host in the code. Instead, consider using environment variables or a configuration file to make it easier to change in different environments.
• 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.

7. backend/pyspur/cli/main.py:112

• Draft comment:
  Typo in the help text: 'protoype' should be changed to 'prototype'.
• 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.

Workflow ID: wflow_sdC9jIYtwIovE0Sr

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.