Porting watchers to Rails and WordPress

The payoff of a stable ingest contract: a watcher I built for Laravel can be ported to other SDKs in an afternoon. Today I did exactly that — auth (and Rails storage) watchers in the Rails and WordPress SDKs.

Same signal, different hooks

The wire shape is identical across SDKs — that was the whole bet from day one. What differs is where each framework exposes the event:

• Rails — auth rides on Warden (after_authentication, before_logout, after_failed_fetch). Warden underpins Devise, so hooking Warden covers Devise apps without double-reporting. Storage maps ActiveStorage's service_upload / download / delete to file.write / read / delete spans.
• WordPress — auth maps to wp_login, wp_logout, wp_login_failed, user_register, after_password_reset. (WordPress has no trace-based filesystem, so storage doesn't apply there — knowing where a feature doesn't belong is half the work.)

The Ruby 2.7 tax

Fix Rails SDK test suite on Ruby 2.7. Supporting an older Ruby means living without newer syntax sugar, and the test suite caught a few places I'd reached for it. Annoying, but the right call: people run real apps on older runtimes, and an observability SDK that only works on the latest version is an SDK for nobody's production.

Why parity matters

An observability platform lives or dies on coverage. If Lookout is great for Laravel and mediocre everywhere else, it's a Laravel tool, not a platform. Porting on the same day I build keeps the SDKs from drifting — the contract stays honest because three clients exercise it at once.

Next: stop hard-coding what each SDK collects, and drive it from the server.