[codex] Improve deploy migration logging - #1102
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughThis PR addresses a production incident where a detached migration container ran unobserved during deployment. The fix combines application-level structured logging throughout Postgres and ClickHouse migration phases with CI/CD live container log streaming via ChangesMigration observability enhancement
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
Storybook previews for This comment updates automatically on each PR push. |
There was a problem hiding this comment.
Pull request overview
This PR improves deploy-time migration observability by streaming migration container logs during GitHub Actions deploys and adding clearer phase/progress logging across Postgres and ClickHouse migration steps. It also documents the triggering production incident in the incident baseline to preserve operational context and mitigation guidance.
Changes:
- Stream detached migration container logs live during the deploy workflow instead of only after exit/timeout.
- Add explicit Postgres and ClickHouse phase/progress log lines (lock acquisition, pending counts, ClickHouse migration IDs, and metric_stream backfill ranges).
- Record the “Production Migration Log Blind Spot” incident and mitigation steps in the production incident baseline.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/deploy-web-stack.yml |
Starts docker logs --follow in the background to stream migration logs during deploy while still polling container status. |
src/db/run-migrate.ts |
Adds high-level phase logs around Postgres and ClickHouse migration execution. |
src/db/run-migrate.test.ts |
Updates log assertion to match the new ClickHouse completion log message. |
src/db/migrate.ts |
Adds Postgres migration progress logs (connect, advisory lock wait/acquire, migration counts). |
src/db/clickhouse-migrations.ts |
Adds ClickHouse migration progress logs, including per-migration and per-backfill-range visibility. |
docs/production-incident-baseline.md |
Documents the 2026-05-08 deploy migration log visibility incident, root cause, and mitigation. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/deploy-web-stack.yml:
- Around line 453-454: Replace the bare wait/clear lines with a call to the
existing stop_migration_log_stream helper to avoid an unbounded wait; locate the
block that references migration_log_pid (the two lines "wait
\"$migration_log_pid\" >/dev/null 2>&1 || true" and "migration_log_pid=\"\"")
and invoke stop_migration_log_stream which will kill the logs process and then
wait safely, ensuring migration_log_pid is cleared by that helper or cleared
immediately after the call.
In `@docs/production-incident-baseline.md`:
- Around line 3395-3435: Add a new "Follow-Up Work" subsection under the
"2026-05-08: Production Migration Log Blind Spot" entry that concisely lists
concrete next steps, owners, and target dates; include items to (1) update the
deploy workflow to stream logs and add the new migration-phase metrics (owner,
deadline), (2) schedule a postmortem action to review long-running queries and
implement DB migration runbook changes (owner, deadline), (3) add automated CI
checks or tests that exercise detached-container migration flow (owner,
deadline), and (4) record any documentation or training updates required; title
the subsection "Follow-Up Work" and keep it a short bulleted list referencing
the incident and the implemented fix.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: b53ac477-7444-45a7-af27-0e789e258b9a
📒 Files selected for processing (6)
.github/workflows/deploy-web-stack.ymldocs/production-incident-baseline.mdsrc/db/clickhouse-migrations.tssrc/db/migrate.tssrc/db/run-migrate.test.tssrc/db/run-migrate.ts
|
Review app is ready: This environment runs on a dedicated Hetzner server for PR #1102 and updates on each push. |
Summary
Root Cause
The deploy workflow started the migration container in detached mode and only printed container logs after completion or timeout. During the production lock wait, Actions only showed repeated
Migration still running...lines, hiding the migration phase and blocking statement.Validation
pnpm lintpnpm test src/db/migrate.test.ts src/db/clickhouse-migrations.test.ts src/db/run-migrate.test.tspnpm tsc --noEmitcd packages/server && pnpm tsc --noEmitcd packages/web && pnpm tsc --noEmitpnpm test:changedwas not run because local Docker could not start this worktree's Postgres dependency: another container (aloud-bike-db-1) is already bound to127.0.0.1:5435.Summary by CodeRabbit
New Features
Documentation
Tests