Implement frontend metrics infra

[aapeliv]

Describe briefly what this PR is doing and why.

Testing

Explain how you tested this PR and give clear steps so the reviewer can replicate.

Backend checklist

• Added tests for any new code or added a regression test if fixing a bug
• Run the backend locally and it works
• Added migrations if there are any database changes, rebased onto develop if necessary for linear migration history

Web frontend checklist

• There are no console warnings when running the app
• Added tests where relevant
• Clicked around my changes running locally and it works
• Checked Desktop, Mobile and Tablet screen sizes

For maintainers

• Maintainers can push commits to my branch
• Maintainers can merge this PR for me

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
couchers	Ready	Preview	Feb 22, 2026 7:39am

[couchersbot]

Claude finished @aapeliv's task in 1m 22s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Posted detailed migration review as a separate comment.

The migration f1a2b3c4d5e6_add_value_and_source_to_eventlog.py follows the correct pattern (add nullable → backfill → set NOT NULL with server defaults). The only minor concern is performance if event_log is very large, since the backfill UPDATEs will touch every existing row in a single transaction.

[couchersbot]

Migration Review

One of our most common issues is migrations that don't work with existing data in production. This is very hard to catch with CI, so we have this bot to check for potential problems.

Overall Risk: LOW RISK

Files Reviewed

• 0137_add_value_and_source_to_eventlog.py - Adds value (Float) and source (Enum) columns to logging.event_log, creates eventsource enum type

Findings

• Fabricated Revision ID [MEDIUM]: The revision ID f1a2b3c4d5e6 is sequential hex digits, not randomly generated. The Create Date 2026-02-21 12:00:00.000000 is also suspiciously round. Per repo guidelines: "always use a real source of randomness for any hex values (e.g. secrets.token_hex()) and the real current time for timestamps." Use alembic revision or secrets.token_hex(6) to regenerate.

• Missing server_default on source [LOW]: The migration sets server_default="1.0" for value but does not set a server_default for source. Any raw SQL INSERT that omits source will fail with a NOT NULL violation. All current ORM code paths set source explicitly, so this is safe in practice. Consider adding server_default="backend" for defense in depth.

• Lock Contention & Performance [LOW]: The backfill UPDATEs touch every existing row in a single transaction. The subsequent ALTER COLUMN ... SET NOT NULL acquires an ACCESS EXCLUSIVE lock. If event_log is large, consider batching or running during low-traffic time.

Summary

The migration follows the correct add-nullable → backfill → set-NOT-NULL pattern and the downgrade correctly reverses all changes including dropping the enum. The main concern is the fabricated revision ID and timestamp which should be regenerated. Otherwise safe for production.

[couchersbot]

Claude finished @CouchersBot[bot]'s task in 1m 0s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Posted detailed migration review as a separate comment.

The migration f1a2b3c4d5e6_add_value_and_source_to_eventlog.py follows the correct pattern (add nullable → backfill → set NOT NULL with server defaults). The only minor concern is performance if event_log is very large, since the backfill UPDATEs will touch every existing row in a single transaction.

[couchersbot]

Claude finished @aapeliv's task in 1m 31s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Posted detailed migration review as a separate comment.

The migration f1a2b3c4d5e6_add_value_and_source_to_eventlog.py follows the correct pattern (add nullable → backfill → set NOT NULL with server defaults). The only minor concern is performance if event_log is very large, since the backfill UPDATEs will touch every existing row in a single transaction.

[couchersbot]

Claude finished @CouchersBot[bot]'s task in 1m 22s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Posted detailed migration review as a separate comment.

The migration f1a2b3c4d5e6_add_value_and_source_to_eventlog.py follows the correct pattern (add nullable → backfill → set NOT NULL with server defaults). The only minor concerns are performance if event_log is very large, since the backfill UPDATEs will touch every existing row in a single transaction.

[couchersbot]

Claude finished @aapeliv's task in 2m 2s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Posted detailed migration review as a separate comment.

The migration 0137_add_value_and_source_to_eventlog.py follows the correct pattern (add nullable → backfill → set NOT NULL with server defaults). Three minor findings: (1) performance concern if event_log is very large since backfill UPDATEs touch every existing row in a single transaction, (2) server_default="1" set on value in migration but not in model, (3) revision ID f1a2b3c4d5e6 appears fabricated rather than randomly generated.

[couchersbot]

Claude finished @CouchersBot[bot]'s task in 1m 32s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Updated the existing migration review comment and posted inline comments on two specific lines.

The migration 0137_add_value_and_source_to_eventlog.py follows the correct add-nullable → backfill → set-NOT-NULL pattern. Two items flagged: (1) the revision ID and timestamp appear fabricated rather than randomly generated per repo guidelines, and (2) the source column is missing a server_default.

[couchersbot]

Per repo guidelines (CLAUDE.md): "always use a real source of randomness for any hex values (e.g. secrets.token_hex()) and the real current time for timestamps - never fabricate or hardcode these values"

f1a2b3c4d5e6 is sequential hex digits, not randomly generated. The Create Date 2026-02-21 12:00:00.000000 also looks fabricated. Please regenerate both using:

import secrets; secrets.token_hex(6)  # for the revision ID

and the actual current timestamp for the Create Date.

Note: the ordinal env.py will handle the revision ID automatically if you use alembic revision, but if creating manually, use real randomness.

[couchersbot]

Consider adding server_default="backend" here for defense in depth, matching what was done for value on the line above. Without it, any raw SQL INSERT that omits source will fail with a NOT NULL violation.

Suggested change

	op.alter_column("event_log", "source", nullable=False, schema="logging")
	op.alter_column("event_log", "source", nullable=False, server_default="backend", schema="logging")

[couchersbot]

Claude finished @aapeliv's task in 1m 11s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Updated the existing migration review comment.

The migration 0137_add_value_and_source_to_eventlog.py follows the correct add-nullable → backfill → set-NOT-NULL pattern. Three findings: (1) revision ID f1a2b3c4d5e6 and timestamp appear fabricated rather than randomly generated, (2) source column is missing a server_default, (3) minor lock contention concern if event_log is large. The downgrade correctly reverses all changes including dropping the enum.

[couchersbot]

Claude finished @CouchersBot[bot]'s task in 1m 34s —— View job

---

Migration Safety Review

• Get PR diff and identify migration files
• Read migration files and related models
• Check production schema context
• Evaluate against review checklist
• Post review summary

Result: LOW RISK - Updated the existing migration review comment and posted inline comments on two specific lines.

The migration 0137_add_value_and_source_to_eventlog.py follows the correct add-nullable → backfill → set-NOT-NULL pattern. Three items flagged: (1) the revision ID f1a2b3c4d5e6 and timestamp appear fabricated rather than randomly generated per repo guidelines, (2) the source column is missing a server_default, and (3) minor lock contention concern if event_log is large. The downgrade correctly reverses all changes including dropping the enum.

[couchersbot]

Per repo guidelines (CLAUDE.md): "always use a real source of randomness for any hex values (e.g. secrets.token_hex()) and the real current time for timestamps - never fabricate or hardcode these values"

f1a2b3c4d5e6 is sequential hex digits, not randomly generated. The Create Date 2026-02-21 12:00:00.000000 also looks fabricated. Please regenerate both using:

import secrets; secrets.token_hex(6)  # for the revision ID

and the actual current timestamp for the Create Date.

Note: the ordinal env.py handles the revision ID automatically if you use alembic revision, but if creating manually, use real randomness.

[couchersbot]

Consider adding server_default="backend" here for defense in depth, matching what was done for value on the line above. Without it, any raw SQL INSERT that omits source will fail with a NOT NULL violation.

Suggested change

	op.alter_column("event_log", "source", nullable=False, schema="logging")
	op.alter_column("event_log", "source", nullable=False, server_default="backend", schema="logging")