fix(copilot): fix copilot stats updates

[Sg312]

Summary

Fixes copilot stats

Fixes #(issue)

Type of Change

• Bug fix

Testing

Manual

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
sim	Ready	Preview	Comment	Sep 3, 2025 8:18pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
docs	Skipped			Sep 3, 2025 8:18pm

[greptile-apps]

Greptile Summary

This PR refactors the copilot statistics tracking system by consolidating and simplifying how usage metrics are collected throughout the application. The changes remove redundant stats tracking code from multiple locations and centralize the collection to only occur during meaningful user interactions.

Specifically, the PR removes comprehensive stats tracking from the copilot store that was collecting detailed metrics like agent depth, max enabled settings, diff creation status, duration, and token usage throughout the entire message lifecycle. It also eliminates early stats tracking from workflow tools (build-workflow.ts and edit-workflow.ts) that were sending premature updates before users could review changes.

The API endpoint schema has been dramatically simplified from 11 optional fields to only 3 required fields: messageId, diffCreated, and diffAccepted. This removes automatic userId injection, timestamps, and other optional analytics data. Stats are now only collected at the workflow diff store level when users actually accept or reject proposed changes, providing more meaningful usage analytics focused on actual user interactions rather than system events.

The refactoring eliminates duplicate tracking, reduces potential race conditions, and moves from a verbose frontend-driven approach to a streamlined server-side collection model. This fits well with the application's architecture by centralizing data collection and reducing the complexity of client-side stores.

PR Description Notes:

• The template fields remain unfilled (Summary, Type of Change, Testing sections)
• No issue number is referenced despite the "Fixes #(issue)" placeholder
• All checklist items remain unchecked

Confidence score: 4/5

• This PR is generally safe to merge but may impact analytics capabilities due to reduced data collection
• Score reflects good code simplification but concerns about potential gaps in usage tracking and unfilled PR description
• Pay close attention to the API route changes and ensure the simplified schema meets all analytics requirements

_{5 files reviewed, 1 comment}

_{Edit Code Review Bot Settings | Greptile}

[greptile-apps]

style: unnecessary type assertion - parsed.data is already properly typed

Suggested change

	const { messageId, diffCreated, diffAccepted } = parsed.data as any
	const { messageId, diffCreated, diffAccepted } = parsed.data

Context Used: Context - Avoid using type assertions to 'any' in TypeScript. Instead, ensure proper type definitions are used to maintain type safety. (link)