fix(analytics): run AccountStore blocking calls on std::thread (#1476)

[bingran-you]

Summary

Closes the latent abort path flagged in #1476 (follow-up to #1454 / #1451).

The three remaining tokio::task::spawn_blocking(move || store.…) call sites in scheduler_module::service::analytics — /analytics/track (account resolution + event insert) and /analytics/dashboard — now run on a dedicated std::thread via a new AccountStore::run_blocking helper that awaits the result through tokio::sync::oneshot.

Without this, any Supabase hiccup that causes r2d2 to recycle a broken connection on these endpoints will:

1. Drop a sync postgres::Client on a tokio blocking-pool thread (they carry a runtime Handle).
2. Drop calls Runtime::block_on(close_rendezvous()) → panics with "Cannot start a runtime from within a runtime".
3. Panic fires inside a destructor → non-unwinding → abort() → PM2 restart.

Worker log evidence from the post-#1454 production / staging scan today (2026-04-21): /home/azureuser/.pm2/logs/dw-worker-error.log still contains this exact panic, with prod dw_worker showing 118 PM2 restarts and staging dw_worker 151 restarts accumulated since the last hot-swap window.

Changes

• account_store.rs: add pub async fn run_blocking<F, T> — the await-able counterpart of the existing fire-and-forget record_analytics_event_detached helper. Same thread model, same safety comment calling out the postgres::Client::drop trap.
• service/analytics.rs:
  • track_event → both get_account_by_auth_user and record_analytics_event use AccountStore::run_blocking.
  • get_dashboard → same treatment for the batch r2d2 query closure.
  • Remove the now-unused use tokio::task; import.
  • Inline NOTE: comments at each site pointing back to [P0] dw_worker aborts: sync postgres Client::drop panics in AccountStore::record_analytics_event (prod) #1451 / [P1] analytics.rs /analytics/track still uses tokio::spawn_blocking for AccountStore — latent postgres Drop crash #1476 so future edits don't regress to spawn_blocking.

The follow-up service/billing.rs (5 sites) and service/auth.rs (40+ sites) listed in #1476 are intentionally deferred to keep this PR focused and reviewable.

Test plan

• cargo check -p scheduler_module — clean (pre-existing warnings only).
• cargo test -p scheduler_module analytics (integration tests in CI).
• After merge + deploy, confirm /home/azureuser/.pm2/logs/dw-worker-error.log stops accumulating new postgres-0.19.12/src/connection.rs:66:22 panics on prod / staging.

Refs: #1451, #1454, #1476.

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
dowhiz	Ready	Preview, Comment	Apr 21, 2026 1:20pm

[bingran-you]

One concern before merge: the new helper in DoWhiz_service/scheduler_module/src/account_store.rs:1266 documents that synchronous AccountStore r2d2/postgres work should never run on tokio::task::spawn_blocking, because recycling a postgres::Client there can abort the worker. This PR migrates service/analytics.rs, but the same spawn_blocking(move || store.*) pattern is still present in other async HTTP paths such as DoWhiz_service/scheduler_module/src/service/auth.rs:707 and DoWhiz_service/scheduler_module/src/service/billing.rs:140.

If the root cause is general to AccountStore, the crash path is still reachable through those handlers, so the invariant introduced here is only partially enforced. If analytics is the only affected surface, I think the new helper/docs should be scoped down to say that explicitly; otherwise I’d prefer to migrate the remaining request-path call sites or centralize the safe wrapper before calling this fixed.

This reply was drafted by breeze, an autonomous agent running on behalf of the account owner.

[bingran-you]

One concern before merge: the new helper in DoWhiz_service/scheduler_module/src/account_store.rs documents that synchronous AccountStore r2d2/postgres work should never run on tokio::task::spawn_blocking, because recycling a postgres::Client there can abort the worker. This PR migrates service/analytics.rs, but the same spawn_blocking(move || store.*) pattern is still present in other async HTTP paths such as DoWhiz_service/scheduler_module/src/service/auth.rs and DoWhiz_service/scheduler_module/src/service/billing.rs.

If the root cause is general to AccountStore, the crash path is still reachable through those handlers, so the invariant introduced here is only partially enforced. If analytics is the only affected surface, I think the new helper/docs should be scoped down to say that explicitly; otherwise I’d prefer to migrate the remaining request-path call sites or centralize the safe wrapper before calling this fixed.

This reply was drafted by breeze, an autonomous agent running on behalf of the account owner.