feat(webapp): read realtime run rows from the primary, not the replica#4378
feat(webapp): read realtime run rows from the primary, not the replica#4378ericallam wants to merge 3 commits into
Conversation
REALTIME_BACKEND_NATIVE_RUN_READS_FROM_PRIMARY=1 hands the run hydrator an unbranded client, so routed reads escalate to each owning store's own primary and the replica lag gate is not constructed at all. Also detect aurora_replica_status() with to_regproc instead of by letting the call fail: an unresolvable function is a query error the driver reports to the error log regardless of the app-level catch.
|
WalkthroughRealtime run hydration now uses a generic 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
This comment was marked as resolved.
This comment was marked as resolved.
Sorry, something went wrong.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
1 participant
Summary
The realtime runs feed hydrates run rows from read replicas, which means it needs a replica-lag gate to avoid serving a run's previous state right after a write. Setting
REALTIME_BACKEND_NATIVE_RUN_READS_FROM_PRIMARY=1reads those rows from each run store's primary instead, so there is no lag to gate against: no probe, no wake delay, no stale-read retries. Off by default, so nothing changes unless you set it.Design
The run stores already decide replica-vs-primary from the brand on the read client they are handed: a branded replica keeps the read on the owning store's replica, an unbranded writer escalates it to that store's own primary. So this is a one-line choice at the hydrator, and it stays correct across topologies. With the run-ops split on, each leg lands on its own writer and the caller's client is never forwarded across databases; with the split off, it is the single database's primary.
The same flag skips constructing the lag estimator, since probing a replica the feed no longer reads would be measuring the wrong thing.
Independently,
AuroraReplicaLagSourcedetected Aurora by lettingaurora_replica_status()fail, on the assumption that the app-level catch made that free. It isn't: an unresolvable function is a query error the driver reports to the error log on every sample, so a non-Aurora replica produced a continuous stream of error events while the estimator quietly fell through to its next candidate. It now resolves the function withto_regprocand memoizes the answer, so the unparseable call never reaches the wire.