‹ Reports
The Dispatch

OSS Watchlist: posthog/posthog


Executive Summary

PostHog is an open-source analytics platform designed for product analytics, session recording, feature flagging, and A/B testing. It is tailored for self-hosting to ensure users maintain control over their data while leveraging advanced analytics tools. The project is actively maintained on GitHub, showing a robust state with continuous improvements and a positive trajectory.

Recent Activity

Team Contributions:

Collaboration Patterns:

Risks

Plans

Conclusion

The PostHog project exhibits a strong commitment to enhancing its platform with a focus on both user experience and technical robustness. Recent activities suggest a proactive approach in addressing both new feature integrations and maintenance issues. However, challenges such as managing technical debt and ensuring feature stability need continued attention. Overall, the project is well-positioned for sustained growth and improvement.

Quantified Commit Activity Over 5 Days

Developer Avatar Branches PRs Commits Files Changes
Paul D'Ambra 1 21/20/0 20 56 16339
vs. last report = +8/+12/-1 +10 +23 +12954
David Newell 1 12/8/1 8 19 7022
vs. last report = -2/-8/= -9 -32 +4817
Michael Matloka 1 12/13/0 13 99 6418
vs. last report -2 -5/=/= -7 +25 +2029
Ben White 1 17/8/2 12 95 3751
vs. last report = =/-6/+2 -5 -29 -10873
Thomas Obermüller 1 9/6/1 6 43 3649
Robbie 1 10/8/1 8 32 3215
vs. last report -1 +6/+5/+1 +3 -14 +2170
Li Yi Yu 1 0/0/0 1 44 1842
Julian Bez 1 10/8/0 11 110 1667
vs. last report = =/=/= +3 -280 -5463
Marius Andra 1 9/9/0 10 75 1420
vs. last report = -4/-2/= -1 +9 -205
Tom Owers 1 16/11/1 13 37 1328
vs. last report = +8/+4/+1 +6 -16 -785
Sandy Spicer 3 9/6/2 13 40 1036
vs. last report +2 +8/+6/+2 +4 +30 -911
Eric Duong 1 10/8/0 8 15 1018
vs. last report = +2/-1/= -2 -12 +200
Neil Kakkar 1 1/1/0 2 7 552
vs. last report = -2/=/= +1 -6 +181
Bianca Yang 5 6/3/0 11 13 474
vs. last report +4 +3/=/= +8 +7 +353
Tomás Farías Santana 1 2/0/0 1 6 445
vs. last report = -4/-5/= -5 -6 +104
Nikita Vorobev 1 2/1/0 2 33 443
vs. last report = +1/+1/= = -4 -9
Zach Waterfield 1 2/3/0 4 37 419
vs. last report = -4/-2/= -1 +25 +240
Brett Hoerner 2 4/3/0 4 10 200
vs. last report +1 +1/-1/= = -7 -460
Joe Martin 1 1/1/0 2 6 152
vs. last report = =/=/= +1 +1 +2
PostHog Bot 1 3/3/0 3 2 129
vs. last report = -3/-1/= -1 = +6
Xavier Vello 1 2/2/0 2 7 126
vs. last report = =/+1/= +1 +5 +117
Phani Raj 1 4/3/1 3 6 81
Raquel Smith 1 4/2/1 2 5 81
vs. last report = +2/+1/+1 +1 +1 +49
Marcus Hof 1 1/1/0 1 4 31
vs. last report = =/=/= -1 -1 -20
Frank Hamand 1 2/3/0 3 2 24
vs. last report = -4/-3/= -3 = -20
Juraj Majerik 1 2/2/0 2 12 14
vs. last report = -2/-1/= -1 = -444
Tiina Turban 1 4/0/1 1 4 11
vs. last report = +3/-1/+1 -2 -25 -582
James Greenhill 1 1/1/0 1 1 3
vs. last report = =/=/= = = =
Vladislav Supalov 1 1/1/0 1 1 2
Cory Watilo 1 2/1/1 1 1 2
Peter Abordan (Pety99) 0 1/0/0 0 0 0
Steven Shults (slshults) 0 1/0/0 0 0 0
Aryan Rawlani (aryanrawlani28) 0 1/0/0 0 0 0
vs. last report -1 =/=/= -1 -5 -139
None (dependabot[bot]) 0 3/0/1 0 0 0
github-actions 3 0/0/0 9 34 0
vs. last report = =/=/= +1 +23 -340

PRs: created by that dev and opened/merged/closed-unmerged during the period

Detailed Reports

Report On: Fetch commits



Project Overview

The PostHog development team has been actively enhancing the platform's features and addressing various issues. The project, hosted on GitHub, is an open-source analytics platform that provides product analytics, session recording, feature flagging, and A/B testing capabilities. It is designed for self-hosting, allowing users to maintain control over their data while using the platform's extensive analytics and optimization tools.

Recent Development Activities:

Team Contributions:

  • David Newell (daibhin) focused on UI improvements and error clustering features.
  • Tiina Turban (tiina303) worked on batch exports and pipeline UI enhancements.
  • Marius Andra (mariusandra) contributed to trends insights and HogQL functions.
  • Julian Bez (webjunkie) made significant updates to the CSV exporter and insights loading optimizations.
  • Tomás Farías Santana (tomasfarias) enhanced batch export functionalities.
  • Michael Matloka (Twixes) improved error handling and toolbar UX.
  • Eric Duong (EDsCODE) worked on data warehouse source settings and UI adjustments.
  • Neil Kakkar (neilkakkar) focused on experiments related to secondary metrics significance.
  • PostHog Bot (posthog-bot) updated dependencies across several files.
  • Frank Hamand (frankh) managed deployment configurations and environment variables.
  • Nikita Vorobev (nikitaevg) contributed to HogQL functions.
  • Robbie (robbie-c) improved web analytics queries and session filters.
  • Juraj Majerik (jurajmajerik) enhanced experiment views and diagnostics.
  • Tom Owers (Gilbert09) focused on syncing warehouse schemas and Stripe source connections for data warehouses.
  • Brett Hoerner (bretthoerner) optimized person state management in the plugin server.
  • Xavier Vello (xvello) improved message parsing performance in the plugin server.
  • Ted Kaemming (tkaemming) worked on optimizing Kafka producer flushes during management commands.

Branch Activity:

Active branches include:

  • allow-billing-tickets-on-free-tier
  • batch-export-delete
  • brett/lazy-persons
  • balance-frontend
  • brett/revert-depot
  • add-session-filters
  • billing-q2-auto-subscribe-new-users
  • brett/test

Conclusions:

The PostHog development team continues to demonstrate a strong commitment to enhancing the platform's functionality and user experience. The recent activities indicate a balanced focus on both front-end improvements and back-end stability, ensuring that PostHog remains a robust solution for product analytics. The ongoing efforts in optimizing data handling and improving integration capabilities are particularly noteworthy, reflecting the team's proactive approach to addressing user needs and technological advancements.

Report On: Fetch issues



Recent Activity Analysis

Overview

Since the last report 5 days ago, there has been a significant amount of activity in the repository, including both the opening and closing of numerous issues. This indicates an active development cycle with ongoing discussions and updates on existing issues.

Notable New Issues

  • Issue #22086: Revert of a previous fix related to query caching.
  • Issue #22085: Reports of broken HogQL subscriptions.
  • Issue #22084: A fix for handling old network plugin data.
  • Issue #22083: A fix related to data warehouse joins.
  • Issue #22081: A UI error in modal behavior.
  • Issue #22079: Temporary skip of large payloads in webhook sends.
  • Issue #22078: Addition of more snapshots for testing.
  • Issue #22077: Capability added for editing S3 table schemas.

Recently Closed Issues

  • Issue #22082: Fixed an overflow issue in survey preview select.
  • Issue #22080: Made code snippet safer for unexpected content.
  • Issue #22074: Allowed larger max query length for HogQL.
  • Issue #22071: Always show PoE v1 option in settings.
  • Issue #22070: Implemented pagination for Replay using HogQL.
  • Issue #22068: Unskipped some previously skipped tests.
  • Issue #22067: Removed experimental replay ingester.

General Trends

There is a continued focus on improving user experience through UI enhancements and fixing glitches. Enhancements in backend functionalities and data handling are evident, suggesting improvements in performance and usability. Rapid opening and closing of some issues indicate a dynamic and responsive development environment.

Conclusion

The recent activity in the repository suggests a healthy and active development cycle focused on both expanding features and maintaining the system's integrity. The project's responsiveness to issues, both in terms of introducing enhancements and resolving bugs, indicates a strong commitment to user satisfaction and continuous improvement.

Report On: Fetch PR 22084 For Assessment



PR #22084

Summary of Changes

This pull request (PR) addresses an issue with handling old network plugin data from a specific range of old posthog-js versions. The problem was that the system did not handle the old data format well, causing errors for users with outdated versions. The solution implemented in this PR is to modify the error handling so that it gracefully handles these cases by providing an empty json tab for network requests instead of throwing an error.

Code Quality Assessment

  1. Error Handling Improvement: The PR improves the system's robustness by adding error handling for outdated data formats. This ensures that the application remains stable and functional even when encountering legacy data formats.

  2. Code Comments and Clarity: The changes include comments explaining why certain code blocks are necessary, which helps in maintaining the code. For example, a comment explains the removal of an outdated comment, clarifying the current state of the code.

  3. Minimal Changes: The changes are minimal and focused directly on the issue at hand, which is typically a good practice as it avoids introducing new bugs or side effects.

  4. Snapshot Updates: The PR includes updates to UI snapshots to reflect changes in how network events are handled and displayed, ensuring that the UI remains consistent with the backend logic.

  5. Review and Collaboration: The PR has been reviewed by another developer who suggested a minor improvement, indicating a collaborative approach to the code changes.

Conclusion

The PR effectively addresses a specific backward compatibility issue with handling network plugin data from older versions of posthog-js. The changes improve error handling and user experience without altering core functionalities. Given the focused nature of the changes and the inclusion of snapshot updates to ensure UI consistency, the code quality appears to be solid. This PR should help enhance stability for users running older versions of related plugins or libraries.

Report On: Fetch pull requests



Since the last analysis 5 days ago, there has been significant activity in the PostHog/posthog repository. Here's a detailed report of the changes:

Open Pull Requests

  1. PR #22086: A revert to a previous commit related to query caching. This indicates a potential issue with the original implementation that needed to be rolled back.
  2. PR #22084: Fixes handling for very old network plugin data, improving error handling and user experience.
  3. PR #22083: Addresses issues with linking persons and events in data warehouse queries, suggesting ongoing improvements in data handling and query optimization.
  4. PR #22079: A temporary fix to skip large payloads on webhook sends, indicating ongoing performance optimizations or bug fixes.
  5. PR #22078: A minor update for snapshot management, likely part of routine maintenance or testing enhancements.

Notable Closed Pull Requests

  1. PR #21996: Conversion of PostgreSQL import to asynchronous processing, suggesting improvements in performance and efficiency.
  2. PR #21990: Introduction of sparklines for batch exports, enhancing visual data representation and user interface.
  3. PR #21989: Fixes an issue with trends actors when using monthly active users aggregation, improving reliability and accuracy of analytics features.

Summary

The recent activity shows a focus on improving performance, handling edge cases, and enhancing user interface elements. Notably:

  • The revert in PR #22086 suggests a cautious approach to new features that may affect system stability.
  • Several PRs (e.g., PR #22084 and PR #22083) focus on refining existing functionalities and improving error handling, which is crucial for maintaining a robust platform.
  • New features like sparklines (PR #21990) indicate ongoing efforts to enhance the analytical capabilities of PostHog.

This level of activity suggests a healthy and active development cycle aimed at both expanding capabilities and ensuring the reliability of the platform.

Report On: Fetch PR 22086 For Assessment



PR #22086

Overview

This pull request reverts a previous change made in PR #22050, which aimed to make all queries cacheable. The revert indicates that there might have been issues or unintended consequences with the original changes.

Code Quality Assessment

  • Clarity and Readability: The changes in this PR are straightforward as they primarily involve reverting previous changes. The use of clear commit messages and comments helps in understanding the context of the revert.

  • Error Handling: The revert includes adjustments in error handling, particularly in how queries are processed when caching is involved. This suggests an attempt to simplify or correct the logic to prevent potential bugs.

  • Maintainability: Reverting changes can be a double-edged sword regarding maintainability. On one hand, it might resolve immediate issues caused by the previous changes; on the other, it could indicate challenges in evolving the codebase sustainably.

  • Performance Implications: The original changes were intended to enhance performance by making queries cacheable. Reverting these changes might have implications on performance, potentially negating improvements if those changes were effective.

  • Security Concerns: There are no direct indications of security impacts from the diff provided. However, any change in how data queries are handled should always be scrutinized for potential security implications.

Specific Observations:

  • Changes in query.py show modifications in how queries are handled, particularly around caching and execution modes. This suggests that the original implementation might have introduced complexities or bugs that necessitated a revert.

  • The discussion and comments from bots about existing issues in related functions provide valuable insights into potential areas of concern that might have influenced the decision to revert.

Conclusion

The decision to revert a feature aimed at enhancing query cachability highlights challenges in implementing performance optimizations without introducing new issues. While reverting may solve immediate problems, it also points to the need for a robust testing and validation process before such changes are reintroduced. The quality of the code change itself is neutral, but the context implies careful consideration was given to the impact of maintaining the original changes versus reverting them.

Report On: Fetch Files For Assessment



Analysis of Source Code Files

1. EventDebugMenu.tsx

Purpose: This file is part of the toolbar's debug menu, specifically for event debugging in the PostHog application.

Structure and Quality:

  • Components and Logic Separation: The file uses a ToolbarMenu component structured with a header, body, and footer. The logic is separated using the eventDebugMenuLogic from Kea (a state management library), which is good practice.
  • UI Components: It uses custom UI components like LemonCheckbox, LemonInput, and LemonSegmentedButton, which suggests a consistent UI framework across the project.
  • Readability: The code is well-organized with clear separation of concerns, making it easy to read. The use of modern React functional components with hooks (useState, useValues) is a good practice.
  • Performance Considerations: The use of memoized selectors or similar optimizations isn't visible here, which might be something to consider given this component deals with potentially large datasets (events).
  • Potential Improvements:
    • Adding PropTypes or TypeScript types could enhance maintainability and developer experience by providing type safety.
    • More granular components could be beneficial if the logic within this component grows.

2. SurveyFormAppearance.tsx

Purpose: Manages the appearance settings of survey forms within the application.

Structure and Quality:

  • Component Design: The component conditionally renders different views based on the survey type, which is a straightforward approach for handling multiple form types.
  • State Management: Uses local state management effectively to handle UI states like active preview indices.
  • UI Consistency: Utilizes custom components such as LemonSelect for dropdowns, maintaining consistency in user interface design.
  • Code Clarity: The code is concise and well-commented where necessary, especially in rendering conditional UI elements.
  • Potential Improvements:
    • Could benefit from error handling mechanisms if the data fetching or state updates fail.
    • Integration of TypeScript could provide better handling of props and state for type safety.

3. CodeSnippet.tsx

Purpose: A reusable component to display code snippets with syntax highlighting across the application.

Structure and Quality:

  • Syntax Highlighting: Integrates react-syntax-highlighter for syntax highlighting, supporting multiple programming languages which is a robust choice for such functionality.
  • Customization: Allows customization through props such as language, wrap, and compact, making it highly reusable.
  • UI Components: Uses custom buttons and icons for actions like copy-to-clipboard, expand/collapse which enhances user interaction.
  • Performance Considerations: Efficient text handling for large code snippets with expand/collapse functionality based on line count.
  • Potential Improvements:
    • Could include more interactive features such as line number toggling or specific text highlighting.
    • Better accessibility features could be considered, ensuring all users can interact with the component effectively.

4. PersonsOnEvents.tsx

Purpose: Configures how person-related data should be handled in event queries within project settings.

Structure and Quality:

  • Functional Design: Clearly separates different modes of operation through radio buttons, providing a clean user interface for configuration.
  • State Management: Leverages local state effectively alongside global state management from teamLogic.
  • UI Consistency: Consistent use of custom UI components like LemonButton and LemonRadio.
  • Code Clarity: The code is straightforward with clear labeling and adequate separation between UI elements and logic handling.
  • Potential Improvements:
    • Could potentially integrate more detailed help or tooltips to guide users on the implications of each setting.

5. test_funnel.ambr (Snapshot File)

Purpose: Contains snapshot tests for funnel queries, ensuring that changes in query logic do not break existing functionalities unexpectedly.

Structure and Quality:

  • Test Coverage: Appears to cover a comprehensive range of scenarios given the size of the snapshot file, which is crucial for complex query functions like funnels.
  • Maintenance Considerations: Large snapshot files can be difficult to maintain and review in pull requests; thus, ensuring they are well-documented and divided can mitigate these issues.
  • Potential Improvements:
    • Periodic reviews of snapshot relevance could help keep the test suite efficient and relevant.
    • More granular snapshots might help in faster pinpointing of issues when tests fail.

Conclusion

The reviewed files demonstrate good software engineering practices with clear structure, separation of concerns, and consistent use of UI components. Enhancements such as increased use of type safety with TypeScript, better documentation for complex logic parts, and more detailed testing could further improve the quality and maintainability of the codebase.