feat(analytics): X + LinkedIn analytics on ClickHouse - #645
Conversation
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Comp AI code review complete — no issues found. Commit |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
4 Skipped Deployments
|
|
Capy auto-review is paused for this organization because the usage-cycle auto-review limit has been reached. Increase the limit or turn it off in billing settings to resume automatic reviews. |
|
React Doctor found 23 new issues in 7 files · 5 errors & 18 warnings · score 49 / 100 (Critical) · 0 fixed · vs Errors
18 warnings
Reviewed by React Doctor for commit |
![github-code-quality[bot]](https://avatars.githubusercontent.com/u/9919?s=60&v=4){kind=small}
| export async function socialAnalyticsSyncWorkflow( | ||
| payload: SocialAnalyticsSyncPayload | ||
| ): Promise<SocialAnalyticsSyncResult> { | ||
| "use workflow"; |
| export async function listSyncableAccounts( | ||
| organizationId?: string | ||
| ): Promise<SyncableSocialAccount[]> { | ||
| "use step"; |
| export async function snapshotAccountDimensions( | ||
| accounts: SyncableSocialAccount[] | ||
| ): Promise<number> { | ||
| "use step"; |
| export async function syncTwitterAnalytics( | ||
| accounts: SyncableSocialAccount[] | ||
| ): Promise<{ accountStats: number; posts: number }> { | ||
| "use step"; |
Greptile SummaryThe PR adds a Tinybird-backed social analytics package, an hourly ingestion workflow, publish-source attribution, a typed dashboard API, and a new analytics dashboard with shared chart primitives.
Confidence Score: 4/5The analytics ingestion and publish-attribution failures should be fixed before merging because they can silently report completed work while permanently omitting or inconsistently classifying posts. Non-OK X responses are converted into partial successful syncs, delayed publish results bypass analytics recording, and sequential post/source writes can leave adoption data inconsistent with the general post dataset. Files Needing Attention: apps/dashboard/src/lib/analytics/twitter-sync.ts, apps/dashboard/src/lib/social-connect/publish.ts, apps/dashboard/src/lib/analytics/record-post.ts Important Files Changed
Sequence DiagramsequenceDiagram
participant Q as QStash
participant W as Analytics workflow
participant X as X API
participant T as Tinybird
participant D as Dashboard
Q->>W: Hourly signed trigger
W->>X: Fetch users and timelines
W->>T: Ingest account/post snapshots
D->>T: Query organization analytics
T-->>D: Overview and chart datasets
Reviews (1): Last reviewed commit: "feat(analytics): add X and LinkedIn anal..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| const response = await twitterAppFetch( | ||
| `https://api.x.com/2/users/by?${params.toString()}` | ||
| ); |
There was a problem hiding this comment.
When X returns a rate-limit or transient error response, the batch lookup silently skips up to 100 accounts and timeline pagination silently drops all remaining pages. The workflow then reports completion without retrying, leaving those accounts or posts absent from the analytics dataset.
| if (platformPostId) { | ||
| yield* Effect.promise(() => | ||
| recordPublishedSocialPost({ | ||
| organizationId: params.organizationId, | ||
| accountId: params.accountId, | ||
| provider: account.provider, | ||
| providerAccountId: account.providerAccountId, | ||
| platformPostId, | ||
| url: postUrl, | ||
| content: params.content, | ||
| }) | ||
| ); | ||
| } |
There was a problem hiding this comment.
When the provider accepts a post but does not return its platform ID within the five polling attempts, this guard skips recordPublishedSocialPost. The published post never enters either Tinybird datasource, so adoption and subsequent post analytics permanently omit it.
Knowledge Base Used: Dashboard Social Account Connect & Publish
| ]); | ||
| await ingestSocialPostSources([ | ||
| { | ||
| organization_id: input.organizationId, | ||
| provider: input.provider, | ||
| provider_account_id: input.providerAccountId, | ||
| platform_post_id: input.platformPostId, | ||
| source: "notra", | ||
| captured_at: now, | ||
| }, |
There was a problem hiding this comment.
When the post ingest succeeds but the subsequent source ingest fails, the catch only logs the error and returns. General post analytics then include the post while adoption analytics undercount Notra posts and can report the wrong first Notra publication, with no retry path to restore the missing source row.
Knowledge Base Used: Dashboard Social Account Connect & Publish
![comp-ai-code-review[bot]](https://avatars.githubusercontent.com/in/2105518?s=60&v=4){kind=small}
There was a problem hiding this comment.
No blocking issues found across the changed files.
1 other commit review still in progress for this PR — findings may follow.
Commit 1262b8d · Posted by Comp AI Code Reviews.
There was a problem hiding this comment.
2 issues found across 2 files.
Prompt for AI agents (all issues)
Check whether each issue below is valid; if so, find the root cause and fix it. Read the referenced code to confirm the problem before changing it, and use sub-agents to handle independent issues in parallel.
<file name="apps/dashboard/src/components/analytics/top-posts-card.tsx">
<issue n="1" at="apps/dashboard/src/components/analytics/top-posts-card.tsx:62-67" severity="MEDIUM">Unvalidated external URL rendered as anchor href enables javascript: scheme XSS — In PostRow, `post.url` is rendered directly as the `href` of an `<a target="_blank">` element with no scheme validation: `<a href={post.url} rel="noopener noreferrer" target="_blank">`. React does not strip `javascript:` URLs from `href` attributes (it only logs a dev-mode warning), so a value like `javascript:alert(document.cookie)` would execute arbitrary script in the victim's session when the link is clicked. Tracing the data flow: `post.url` originates from `TopPostItem.url`, returned by the `analytics.topPosts` oRPC handler (apps/dashboard/src/lib/orpc/routers/analytics.ts) as `row.url` straight from Tinybird with no sanitization. The value is ingested via `recordPublishedSocialPost` (apps/dashboard/src/lib/analytics/record-post.ts) whose `url` field is set in `publishSocialPost` (apps/dashboard/src/lib/social-connect/publish.ts:128) from `postResult?.platform_data?.url` — i.e. an EXTERNAL social-connect service response that crosses a trust boundary into the analytics store and back out to the client. Unlike other URL fields in this codebase that are explicitly validated (e.g. `add-identity-dialog.tsx:53` requires `startsWith("https://")`, `format-tweet-content.tsx:54` rejects non-http(s) hrefs), this ingestion/storage/retrieval path performs no `http(s)://` scheme check. Practical exploitability is limited because under normal operation the URL is platform-derived (the constructed path is always `https://x.com/...` and `platform_data.url` is expected to be a platform canonical URL), so a normal org member cannot directly inject the value. However, it is a genuine trust-boundary / defense-in-depth gap: any compromise or unexpected response from the social-connect service, or any future code path that writes a less-trusted value into the `social_posts.url` column, would turn into stored XSS in the analytics dashboard with no backstop. Note: the other URL-rendering surface in these files, `account.profileImageUrl` / `post.profileImageUrl` rendered as `<img src>`, is NOT exploitable because browsers do not execute `javascript:` URLs in image `src` attributes. Fix: Validate the URL scheme before rendering. The simplest fix is to sanitize at the render site in PostRow: only render the `<a>` when `post.url` starts with `http://` or `https://`, otherwise render a non-interactive element or strip the href (mirroring the existing pattern in format-tweet-content.tsx). For defense in depth, also normalize/validate the scheme at ingestion time in record-post.ts / publish.ts so malicious values never enter the analytics store. Do not rely on React to strip `javascript:` URLs — it does not.</issue>
</file>
<file name="packages/analytics/src/utils/datetime.ts">
<issue n="2" at="packages/analytics/src/utils/datetime.ts:7-9" severity="MEDIUM">toClickHouseDateTime silently emits malformed datetime for Invalid Date input — toClickHouseDateTime(date) does not validate that the supplied Date is valid. When given an Invalid Date (e.g. `new Date(undefined)` or `new Date(malformedString)`), the Date's getUTC* methods return NaN, and `String(NaN).padStart(2,'0')` yields the literal string 'NaN'. The function then returns a malformed string like 'NaN-NaN-NaN NaN:NaN:NaN'. This is reachable in practice: in apps/dashboard/src/lib/analytics/rows.ts (buildTweetPostRow, line ~65) the posted_at value is computed as `toClickHouseDateTime(tweet.created_at ? new Date(tweet.created_at) : capturedAt)`, where tweet.created_at is external Twitter-API data. If created_at is a non-empty but unparseable string, new Date() returns an Invalid Date and the resulting garbage datetime string is ingested into Tinybird/ClickHouse as a row field value, corrupting data quality for that record (the ingest row's posted_at/captured_at columns receive an invalid datetime). There is no security impact (output is constrained to digits/dashes/colons/NaN, so no SQL or injection vector), but it is a silent data-quality defect with a real caller path. Fix: Guard against Invalid Date before formatting. For example, check `Number.isNaN(date.getTime())` and throw, return null, or fall back to a sensible value. At the call site in rows.ts, validate `new Date(tweet.created_at)` before passing it in, falling back to capturedAt when the parsed date is invalid.</issue>
</file>
Commit f56bf77 · Posted by Comp AI Code Reviews.
| </p> | ||
| <p className="text-sm leading-snug">{previewContent(post.content)}</p> | ||
| <p className="text-muted-foreground text-xs tabular-nums"> | ||
| {formatMetric(post.likes)} likes · {formatMetric(post.replies)}{" "} | ||
| replies · {formatMetric(post.reposts)} reposts | ||
| {post.impressions !== null && |
There was a problem hiding this comment.
MEDIUM: Unvalidated external URL rendered as anchor href enables javascript: scheme XSS
In PostRow, post.url is rendered directly as the href of an <a target="_blank"> element with no scheme validation: <a href={post.url} rel="noopener noreferrer" target="_blank">. React does not strip javascript: URLs from href attributes (it only logs a dev-mode warning), so a value like javascript:alert(document.cookie) would execute arbitrary script in the victim's session when the link is clicked. Tracing the data flow: post.url originates from TopPostItem.url, returned by the analytics.topPosts oRPC handler (apps/dashboard/src/lib/orpc/routers/analytics.ts) as row.url straight from Tinybird with no sanitization. The value is ingested via recordPublishedSocialPost (apps/dashboard/src/lib/analytics/record-post.ts) whose url field is set in publishSocialPost (apps/dashboard/src/lib/social-connect/publish.ts:128) from postResult?.platform_data?.url — i.e. an EXTERNAL social-connect service response that crosses a trust boundary into the analytics store and back out to the client. Unlike other URL fields in this codebase that are explicitly validated (e.g. add-identity-dialog.tsx:53 requires startsWith("https://"), format-tweet-content.tsx:54 rejects non-http(s) hrefs), this ingestion/storage/retrieval path performs no http(s):// scheme check. Practical exploitability is limited because under normal operation the URL is platform-derived (the constructed path is always https://x.com/... and platform_data.url is expected to be a platform canonical URL), so a normal org member cannot directly inject the value. However, it is a genuine trust-boundary / defense-in-depth gap: any compromise or unexpected response from the social-connect service, or any future code path that writes a less-trusted value into the social_posts.url column, would turn into stored XSS in the analytics dashboard with no backstop. Note: the other URL-rendering surface in these files, account.profileImageUrl / post.profileImageUrl rendered as <img src>, is NOT exploitable because browsers do not execute javascript: URLs in image src attributes.
Suggestion: Validate the URL scheme before rendering. The simplest fix is to sanitize at the render site in PostRow: only render the <a> when post.url starts with http:// or https://, otherwise render a non-interactive element or strip the href (mirroring the existing pattern in format-tweet-content.tsx). For defense in depth, also normalize/validate the scheme at ingestion time in record-post.ts / publish.ts so malicious values never enter the analytics store. Do not rely on React to strip javascript: URLs — it does not.
Prompt for AI agents
Check whether this issue is valid; if so, find the root cause and fix it. Read the referenced code to confirm the problem before changing it.
<issue at="apps/dashboard/src/components/analytics/top-posts-card.tsx:62-67" severity="MEDIUM">Unvalidated external URL rendered as anchor href enables javascript: scheme XSS — In PostRow, `post.url` is rendered directly as the `href` of an `<a target="_blank">` element with no scheme validation: `<a href={post.url} rel="noopener noreferrer" target="_blank">`. React does not strip `javascript:` URLs from `href` attributes (it only logs a dev-mode warning), so a value like `javascript:alert(document.cookie)` would execute arbitrary script in the victim's session when the link is clicked. Tracing the data flow: `post.url` originates from `TopPostItem.url`, returned by the `analytics.topPosts` oRPC handler (apps/dashboard/src/lib/orpc/routers/analytics.ts) as `row.url` straight from Tinybird with no sanitization. The value is ingested via `recordPublishedSocialPost` (apps/dashboard/src/lib/analytics/record-post.ts) whose `url` field is set in `publishSocialPost` (apps/dashboard/src/lib/social-connect/publish.ts:128) from `postResult?.platform_data?.url` — i.e. an EXTERNAL social-connect service response that crosses a trust boundary into the analytics store and back out to the client. Unlike other URL fields in this codebase that are explicitly validated (e.g. `add-identity-dialog.tsx:53` requires `startsWith("https://")`, `format-tweet-content.tsx:54` rejects non-http(s) hrefs), this ingestion/storage/retrieval path performs no `http(s)://` scheme check. Practical exploitability is limited because under normal operation the URL is platform-derived (the constructed path is always `https://x.com/...` and `platform_data.url` is expected to be a platform canonical URL), so a normal org member cannot directly inject the value. However, it is a genuine trust-boundary / defense-in-depth gap: any compromise or unexpected response from the social-connect service, or any future code path that writes a less-trusted value into the `social_posts.url` column, would turn into stored XSS in the analytics dashboard with no backstop. Note: the other URL-rendering surface in these files, `account.profileImageUrl` / `post.profileImageUrl` rendered as `<img src>`, is NOT exploitable because browsers do not execute `javascript:` URLs in image `src` attributes. Fix: Validate the URL scheme before rendering. The simplest fix is to sanitize at the render site in PostRow: only render the `<a>` when `post.url` starts with `http://` or `https://`, otherwise render a non-interactive element or strip the href (mirroring the existing pattern in format-tweet-content.tsx). For defense in depth, also normalize/validate the scheme at ingestion time in record-post.ts / publish.ts so malicious values never enter the analytics store. Do not rely on React to strip `javascript:` URLs — it does not.</issue>
Commit f56bf77.
| export function toClickHouseDateTime(date: Date): string { | ||
| return `${date.getUTCFullYear()}-${pad(date.getUTCMonth() + 1)}-${pad( | ||
| date.getUTCDate() |
There was a problem hiding this comment.
MEDIUM: toClickHouseDateTime silently emits malformed datetime for Invalid Date input
toClickHouseDateTime(date) does not validate that the supplied Date is valid. When given an Invalid Date (e.g. new Date(undefined) or new Date(malformedString)), the Date's getUTC* methods return NaN, and String(NaN).padStart(2,'0') yields the literal string 'NaN'. The function then returns a malformed string like 'NaN-NaN-NaN NaN:NaN:NaN'. This is reachable in practice: in apps/dashboard/src/lib/analytics/rows.ts (buildTweetPostRow, line ~65) the posted_at value is computed as toClickHouseDateTime(tweet.created_at ? new Date(tweet.created_at) : capturedAt), where tweet.created_at is external Twitter-API data. If created_at is a non-empty but unparseable string, new Date() returns an Invalid Date and the resulting garbage datetime string is ingested into Tinybird/ClickHouse as a row field value, corrupting data quality for that record (the ingest row's posted_at/captured_at columns receive an invalid datetime). There is no security impact (output is constrained to digits/dashes/colons/NaN, so no SQL or injection vector), but it is a silent data-quality defect with a real caller path.
Suggestion: Guard against Invalid Date before formatting. For example, check Number.isNaN(date.getTime()) and throw, return null, or fall back to a sensible value. At the call site in rows.ts, validate new Date(tweet.created_at) before passing it in, falling back to capturedAt when the parsed date is invalid.
Prompt for AI agents
Check whether this issue is valid; if so, find the root cause and fix it. Read the referenced code to confirm the problem before changing it.
<issue at="packages/analytics/src/utils/datetime.ts:7-9" severity="MEDIUM">toClickHouseDateTime silently emits malformed datetime for Invalid Date input — toClickHouseDateTime(date) does not validate that the supplied Date is valid. When given an Invalid Date (e.g. `new Date(undefined)` or `new Date(malformedString)`), the Date's getUTC* methods return NaN, and `String(NaN).padStart(2,'0')` yields the literal string 'NaN'. The function then returns a malformed string like 'NaN-NaN-NaN NaN:NaN:NaN'. This is reachable in practice: in apps/dashboard/src/lib/analytics/rows.ts (buildTweetPostRow, line ~65) the posted_at value is computed as `toClickHouseDateTime(tweet.created_at ? new Date(tweet.created_at) : capturedAt)`, where tweet.created_at is external Twitter-API data. If created_at is a non-empty but unparseable string, new Date() returns an Invalid Date and the resulting garbage datetime string is ingested into Tinybird/ClickHouse as a row field value, corrupting data quality for that record (the ingest row's posted_at/captured_at columns receive an invalid datetime). There is no security impact (output is constrained to digits/dashes/colons/NaN, so no SQL or injection vector), but it is a silent data-quality defect with a real caller path. Fix: Guard against Invalid Date before formatting. For example, check `Number.isNaN(date.getTime())` and throw, return null, or fall back to a sensible value. At the call site in rows.ts, validate `new Date(tweet.created_at)` before passing it in, falling back to capturedAt when the parsed date is invalid.</issue>
Commit f56bf77.
There was a problem hiding this comment.
1 issue found across 1 file.
Prompt for AI agents (all issues)
Check whether each issue below is valid; if so, find the root cause and fix it. Read the referenced code to confirm the problem before changing it, and use sub-agents to handle independent issues in parallel.
<file name="packages/analytics/src/cache/query-cache.ts">
<issue n="1" at="packages/analytics/src/cache/query-cache.ts:89-93" severity="MEDIUM">Silent cache-version bump failure can serve stale analytics for up to 6 hours — In bumpAnalyticsVersions (L79-94), the Redis pipeline that increments per-organization cache versions is wrapped with Effect.ignore, so any Redis error (network blip, auth failure, timeout) is silently swallowed and the function still resolves successfully. This is called from ingestRows (client.ts L89) AFTER a successful Tinybird ingest: `const result = await ingest(client, rows); await bumpAnalyticsVersions(scope, organizationIds); return result;`. If the ingest succeeds but the version bump fails, the cache version for the affected organization(s) is NOT incremented. The query cache (cachedQuery, L48-76) keys results by the per-org version and caches them with a 6-hour TTL (QUERY_CACHE_TTL_SECONDS = 21600). Consequently, new data written to Tinybird will not be visible to query endpoints until either (a) the version is bumped by a subsequent successful ingest, or (b) the stale cache entries expire (up to 6 hours). This is a user-facing data-staleness bug, not a security issue — the data is still org-scoped and no cross-tenant leakage occurs. It only manifests when Redis is transiently unavailable during an ingest. Fix: Either log the version-bump failure so it is observable (e.g., tap the error before Effect.ignore and emit a warning/metric), or retry the version bump with backoff. If stale reads after ingest are unacceptable, consider failing the ingest or writing the new data under the current version so a subsequent bump invalidates it. At minimum, surface the swallowed error to monitoring so operators know cache invalidation is failing.</issue>
</file>
Commit 741fce5 · Posted by Comp AI Code Reviews.
| const pipeline = redis.pipeline(); | ||
| for (const key of keys) { | ||
| pipeline.incr(key); | ||
| } | ||
| return pipeline.exec(); |
There was a problem hiding this comment.
MEDIUM: Silent cache-version bump failure can serve stale analytics for up to 6 hours
In bumpAnalyticsVersions (L79-94), the Redis pipeline that increments per-organization cache versions is wrapped with Effect.ignore, so any Redis error (network blip, auth failure, timeout) is silently swallowed and the function still resolves successfully. This is called from ingestRows (client.ts L89) AFTER a successful Tinybird ingest: const result = await ingest(client, rows); await bumpAnalyticsVersions(scope, organizationIds); return result;. If the ingest succeeds but the version bump fails, the cache version for the affected organization(s) is NOT incremented. The query cache (cachedQuery, L48-76) keys results by the per-org version and caches them with a 6-hour TTL (QUERY_CACHE_TTL_SECONDS = 21600). Consequently, new data written to Tinybird will not be visible to query endpoints until either (a) the version is bumped by a subsequent successful ingest, or (b) the stale cache entries expire (up to 6 hours). This is a user-facing data-staleness bug, not a security issue — the data is still org-scoped and no cross-tenant leakage occurs. It only manifests when Redis is transiently unavailable during an ingest.
Suggestion: Either log the version-bump failure so it is observable (e.g., tap the error before Effect.ignore and emit a warning/metric), or retry the version bump with backoff. If stale reads after ingest are unacceptable, consider failing the ingest or writing the new data under the current version so a subsequent bump invalidates it. At minimum, surface the swallowed error to monitoring so operators know cache invalidation is failing.
Prompt for AI agents
Check whether this issue is valid; if so, find the root cause and fix it. Read the referenced code to confirm the problem before changing it.
<issue at="packages/analytics/src/cache/query-cache.ts:89-93" severity="MEDIUM">Silent cache-version bump failure can serve stale analytics for up to 6 hours — In bumpAnalyticsVersions (L79-94), the Redis pipeline that increments per-organization cache versions is wrapped with Effect.ignore, so any Redis error (network blip, auth failure, timeout) is silently swallowed and the function still resolves successfully. This is called from ingestRows (client.ts L89) AFTER a successful Tinybird ingest: `const result = await ingest(client, rows); await bumpAnalyticsVersions(scope, organizationIds); return result;`. If the ingest succeeds but the version bump fails, the cache version for the affected organization(s) is NOT incremented. The query cache (cachedQuery, L48-76) keys results by the per-org version and caches them with a 6-hour TTL (QUERY_CACHE_TTL_SECONDS = 21600). Consequently, new data written to Tinybird will not be visible to query endpoints until either (a) the version is bumped by a subsequent successful ingest, or (b) the stale cache entries expire (up to 6 hours). This is a user-facing data-staleness bug, not a security issue — the data is still org-scoped and no cross-tenant leakage occurs. It only manifests when Redis is transiently unavailable during an ingest. Fix: Either log the version-bump failure so it is observable (e.g., tap the error before Effect.ignore and emit a warning/metric), or retry the version bump with backoff. If stale reads after ingest are unacceptable, consider failing the ingest or writing the new data under the current version so a subsequent bump invalidates it. At minimum, surface the swallowed error to monitoring so operators know cache invalidation is failing.</issue>
Commit 741fce5.
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| const [hoverIndex, setHoverIndex] = useState<number | null>(null); | ||
| const [hiddenKeys, setHiddenKeys] = useState<Set<string>>(new Set()); | ||
|
|
||
| const accounts = useMemo( |
There was a problem hiding this comment.
React Doctor · react-doctor/react-compiler-no-manual-memoization (warning)
React Compiler can cache this value automatically. Verify that removing useMemo preserves behavior before simplifying it.
Fix → Profile compiler-managed code and remove useMemo, useCallback, or memo only when the manual cache no longer carries behavioral or performance intent.
| [overview?.accounts] | ||
| ); | ||
|
|
||
| const accountConfig = useMemo(() => { |
There was a problem hiding this comment.
React Doctor · react-doctor/react-compiler-no-manual-memoization (warning)
React Compiler can cache this value automatically. Verify that removing useMemo preserves behavior before simplifying it.
Fix → Profile compiler-managed code and remove useMemo, useCallback, or memo only when the manual cache no longer carries behavioral or performance intent.
| return config; | ||
| }, [accounts]); | ||
|
|
||
| const allKeys = useMemo( |
There was a problem hiding this comment.
React Doctor · react-doctor/react-compiler-no-manual-memoization (warning)
React Compiler can cache this value automatically. Verify that removing useMemo preserves behavior before simplifying it.
Fix → Profile compiler-managed code and remove useMemo, useCallback, or memo only when the manual cache no longer carries behavioral or performance intent.
| [accounts] | ||
| ); | ||
|
|
||
| const visibleKeys = useMemo( |
There was a problem hiding this comment.
React Doctor · react-doctor/react-compiler-no-manual-memoization (warning)
React Compiler can cache this value automatically. Verify that removing useMemo preserves behavior before simplifying it.
Fix → Profile compiler-managed code and remove useMemo, useCallback, or memo only when the manual cache no longer carries behavioral or performance intent.
| [allKeys, hiddenKeys] | ||
| ); | ||
|
|
||
| const selectedKeys = useMemo(() => new Set(visibleKeys), [visibleKeys]); |
There was a problem hiding this comment.
React Doctor · react-doctor/react-compiler-no-manual-memoization (warning)
React Compiler can cache this value automatically. Verify that removing useMemo preserves behavior before simplifying it.
Fix → Profile compiler-managed code and remove useMemo, useCallback, or memo only when the manual cache no longer carries behavioral or performance intent.
| opacity: 0, | ||
| x: "-50%", | ||
| y: "-115%", | ||
| top: chart.tooltipTop, |
There was a problem hiding this comment.
React Doctor · react-doctor/no-layout-property-animation (error)
This stutters because animating "top" makes the browser redo page layout every frame, so animate transform or scale instead, or use the layout prop
Fix → Use transform: translateX() or scale() instead. They animate smoothly without making the browser redo layout or repaint
| x: "-50%", | ||
| y: "-115%", | ||
| top: chart.tooltipTop, | ||
| left: chart.tooltipLeft, |
There was a problem hiding this comment.
React Doctor · react-doctor/no-layout-property-animation (error)
This stutters because animating "left" makes the browser redo page layout every frame, so animate transform or scale instead, or use the layout prop
Fix → Use transform: translateX() or scale() instead. They animate smoothly without making the browser redo layout or repaint
| opacity: 1, | ||
| x: "-50%", | ||
| y: "-115%", | ||
| top: chart.tooltipTop, |
There was a problem hiding this comment.
React Doctor · react-doctor/no-layout-property-animation (error)
This stutters because animating "top" makes the browser redo page layout every frame, so animate transform or scale instead, or use the layout prop
Fix → Use transform: translateX() or scale() instead. They animate smoothly without making the browser redo layout or repaint
| x: "-50%", | ||
| y: "-115%", | ||
| top: chart.tooltipTop, | ||
| left: chart.tooltipLeft, |
There was a problem hiding this comment.
React Doctor · react-doctor/no-layout-property-animation (error)
This stutters because animating "left" makes the browser redo page layout every frame, so animate transform or scale instead, or use the layout prop
Fix → Use transform: translateX() or scale() instead. They animate smoothly without making the browser redo layout or repaint
| return ( | ||
| <text | ||
| // biome-ignore lint/suspicious/noArrayIndexKey: index is the stable x position | ||
| key={i} |
There was a problem hiding this comment.
React Doctor · react-doctor/no-array-index-as-key (warning)
Your users can see & submit the wrong data when this list reorders or filters, so use a stable id like key={item.id}, not the array index "i".
Fix → Use a stable id from the item, like key={item.id} or key={item.slug}. Index keys break when the list reorders or filters.
There was a problem hiding this comment.
No blocking issues found across the changed files.
Commit 3992f49 · Posted by Comp AI Code Reviews.
1 participant
Ships the analytics core: X and LinkedIn metrics ingested into ClickHouse via Tinybird, plus the dashboard surface that reads them.
@notra/analyticspackage: Tinybird datasources (accounts, account stats, posts, post stats, post sources) and pipes (overview, engagement timeseries, top posts, follower growth, posting performance, Notra adoption) with a typed ingest/query client that no-ops whenTINYBIRD_TOKENis unset.social-analytics-sync+ its API route andscripts/register-analytics-schedule.tsto snapshot account dimensions and pull X post metrics on a schedule.social_post_sourcesso adoption markers work./[slug]/analyticspage: summary stats, per-account engagement/impressions/publishing-volume/follower charts with shared hover, posting performance and top posts.dither-kitchart primitives added to@notra/ui(cartesian/polar roots, area, bar, sparkline, axes, legend, tooltip, dither painting).Stack
Summary by cubic
Adds social analytics: ingests X and LinkedIn metrics into ClickHouse via Tinybird and introduces a new
/analyticsdashboard with followers, engagement, posting performance, and top posts. Adds Upstash Redis caching over Tinybird queries, an hourly sync workflow, fixes chart tooltips to show the hovered day heading, and sets a pointer cursor on the account filter.New Features
@notra/analyticspackage: Tinybird datasources (accounts, account stats, posts, post stats, post sources) and endpoints (overview, engagement timeseries, follower growth, posting performance, top posts, Notra adoption) with a typed client that no-ops whenTINYBIRD_TOKENis unset; Upstash Redis query cache with 6-hour TTL and version bumps on ingest to invalidate.scripts/register-analytics-schedule.tsto register the schedule./[slug]/analyticspage with summary stats, per-account charts, follower growth, posting performance, and top posts; account filter and shared hover; loading skeletons; nav item and command palette entry for quick access.social_post_sourcesto power adoption markers.dither-kitchart primitives added to@notra/ui(area/line/bar charts, axes, legend, tooltip, sparkline, dither painting); pointer cursor on account filter.orpcanalytics router + React Query hooks for overview, timeseries, top posts, follower growth, posting performance, and adoption.Migration
TINYBIRD_TOKEN(required),TINYBIRD_BASE_URL(defaults provided),TWITTER_BEARER_TOKEN(enables X sync),QSTASH_TOKEN(for scheduling).UPSTASH_REDIS_REST_URL,UPSTASH_REDIS_REST_TOKENto enable the query cache.apps/dashboard/scripts/register-analytics-schedule.ts.Written for commit 3992f49. Summary will update on new commits.
Summary by Comp AI
No blocking issues found.
Written for commit
3992f49. New commits will trigger a re-review. Generated by Comp AI.