DEV Community: Kane

It didn't crash. It just wouldn't wait.

Kane — Thu, 20 Aug 2026 09:14:48 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

StableRoute is a liquidity router on Stellar. The frontend is a Next.js app: quotes, pairs, admin controls, webhooks, audit logs. Most of it is forms and lists. The stats page is different. It is the room where you look at the protocol and ask a simple question: is it alive?

That page used to look like this.

useEffect(() => {
  const id = setInterval(refetch, POLL_MS);
  return () => clearInterval(id);
}, [refetch]);

Five seconds. Hit /api/v1/stats. Paint the pair count. Paint whether the router is paused. Do it forever. It is the kind of code you write when you want the dashboard to feel live, and you do not yet know what "live" costs.

I found out on a bad afternoon, not a dramatic one. The backend got slow. Not down, just sick. Latency climbed past five seconds. The stats page did not wait. setInterval does not care whether the last request came home. It fires on the clock.

Every five seconds refetch bumped a reload key. The fetch effect tore down the previous request, marked it cancelled, and started another. If the server needed eight seconds, the client never kept a request long enough to finish. The dashboard sat there asking, cancelling, asking again. From the server's side it looked like a client that would not stop poking a bruise.

When the API actually failed, it got worse. A 500 came back fast. The interval did not slow down. It kept hitting every five seconds. The UI flipped from error to loading to error. The alert unmounted and remounted. The page flickered. Anyone with the tab open became part of the outage.

That is the bug. It did not throw. It did not panic a contract. It just refused to be kind when the system needed kindness.

The fix was to stop treating time as the thing that drives the network.

I threw out setInterval and wrote useBackoffInterval. The idea is small enough to hold in your head. A poll is allowed to schedule the next poll only after the current one has settled. Settled means success or error. While status is idle or loading, nothing is scheduled. One request in flight. No pile-up. No cancelled work eating the only response you were going to get.

Failures remember themselves. A ref counts them, not React state, so counting a failure does not itself retrigger the effect. First error waits ten seconds. Then twenty. Then forty. Then it stops at sixty. The formula is the boring one everyone should have used from the start:

delay = Math.min(baseMs * 2 ** failureCount, maxMs)

The first success zeros the counter. The cadence comes back to five seconds without anyone pressing Retry. The page still has a Retry button, because a human should be able to say "try now" without waiting for the backoff clock. Automatic recovery is not the same as trapping someone in a delay.

There was a quieter bug inside the quieter bug. If you put callback in the effect deps, every new function identity kills the timer and starts another. Polling becomes jitter. If you freeze the callback, you poll with a stale closure. The way through is the unfashionable one: keep the latest callback in a ref, update it every render, and let the effect depend on status and timing, not on the function you plan to call.

const callbackRef = useRef(callback);
callbackRef.current = callback;

useEffect(() => {
  if (status !== 'success' && status !== 'error') return;
  // ... count, compute delay, schedule callbackRef.current
  return () => cancel(timeoutId);
}, [baseMs, cancel, maxMs, schedule, status]);

Unmount clears the timeout. I tested that by leaving, advancing fifteen seconds, and counting fetch calls. It stayed at one. That is the whole point of cleanup. Most people write it. Fewer people prove it.

The tests are the part I am actually proud of. I did not want to sit in a browser and wait for a minute of backoff. The hook takes schedule and cancel as arguments. In production those are setTimeout and clearTimeout. In Jest they are mocks. The test can say: you were told to wait 10,000ms, then 20,000, then 40,000, then 60,000, then 60,000 again. It can say: after an error, a success puts you back on 5,000. It can say: if the callback identity changes before the timeout fires, you call the new one, not the old one. It can say: idle and loading schedule nothing.

That is how the page stopped being a liability.

When the router is healthy, the tiles still update every five seconds. The "Updated just now" label still ticks. When the router is not healthy, the page tells you so once, holds the alert still, and backs away. The copy is honest: retrying automatically, with a longer delay, while the service is unavailable. It is not pretending everything is fine. It is also not kicking the thing that is already down.

I would not call this legendary. I would call it the work that makes software feel like it was written by someone who has been on both sides of a slow endpoint. The stats page is a small surface. It is also the first place an operator looks when they are worried. If that page panics, the rest of the product feels like it is panicking with it.

The win was not a clever algorithm. The win was that the dashboard learned how to wait.

PawGuard: A platform responsible for instant Abuse reporting and Community for Dogs in danger

Kane — Sun, 16 Aug 2026 18:19:45 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

PawGuard is a community web platform built to help protect dogs from abuse, severe neglect, and abandonment. When someone spots a dog in danger—whether chained without water, hit by a car, or dumped—they can submit a report in seconds with their GPS location, photos, urgency level, and even stay anonymous if needed. Those alerts are routed directly to local rescue contacts and volunteers via WhatsApp and email so someone can respond quickly.

In addition to emergency reports, the platform includes a noticeboard for lost and found pets (with instant printable flyers), an adoption and foster board, and practical guides on animal welfare.

My main goal with PawGuard was to remove the friction between seeing an animal suffering on the street and actually getting help to them. Too often, people don't know who to call or where to report neglect. PawGuard gives everyday people a direct, fast way to speak up and connects them with volunteers who can step in.

Demo

https://paw-guard-two.vercel.app

Code

https://github.com/comzzy-comzzy/PawGuard

How I Built It

I built PawGuard as a responsive single-page web application using React 18, TypeScript, and Vite, styled with Tailwind CSS and custom CSS animation keyframes.

A few key technical decisions shaped the build:

Zero-Delay Emergency Dispatch: Instead of locking emergency reports behind authentication or waiting on slow backend pipelines, I built client-side triage and routing that immediately bundles report details (GPS coordinates, urgency classification, incident notes) into structured WhatsApp and email dispatch links. Rescuers get the exact location and photos sent directly to their phones in real time.
Dynamic Audio & Custom Animations: Animal rescue platforms can often feel bleak and heavy. I used the Web Audio API for lightweight synthesized sound effects and custom keyframe animations for our canine mascots, creating an engaging, welcoming experience without bloating page load times.
Instant Printable Flyer Generation: For lost and abandoned dogs, we implemented client-side flyer generation directly in the browser so community members can print or share high-visibility search notices immediately.
Guided Intake Companion ("Picky"): I implemented an interactive conversation flow that walks stressed witnesses step-by-step through capturing the essential details needed for a rescue (exact landmarks, condition of the dog, immediate threats).

Best Use of Google AI — Antigravity with Gemini 3.7 (High Reasoning)

I leveraged Google Antigravity powered by Gemini 3.7 (High reasoning mode) as our core development and architectural copilot throughout the project.

With Gemini 3.7's deep multi-step reasoning:

• I architected resilient state flows for complex multi-module forms (abuse intake, foster applications, and lost pet postings).

• I rapidly designed and refined the interactive triage logic and geolocation fallbacks, ensuring reports are formatted accurately even when network conditions or location services are spotty.

• Antigravity helped me implement clean, fully typed TypeScript schemas and custom UI micro-interactions, cutting development time drastically while keeping the codebase modular and maintainable.

Prize Categories

Best Use of Google AI.

Team Submissions: Hi I'm a Solobuilder i havent added anyone yet to my team

StableRoute Frontend: Resilient Polling with Adaptive Exponential Backoff

Kane — Sat, 15 Aug 2026 10:30:04 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

StableRoute Frontend is the web interface for StableRoute, an open-source decentralized liquidity routing protocol built on the Stellar network. The application is built with Next.js (App Router), React, and TypeScript.
The platform provides a comprehensive suite of tools for traders, liquidity providers, and developers:
Payment and Liquidity Routing: An interactive interface for querying optimal swap and cross-currency path routing quotes across Stellar asset pools.
Liquidity Pool Management: Workflows to register, inspect, and configure supported asset pairs.
Real-Time Protocol Monitoring: A live status dashboard that polls protocol health, operational state (active vs. paused), and liquidity pool counts.
Developer and Infrastructure Controls: Management consoles for generating and revoking API keys, registering webhook event subscribers, viewing immutable system audit logs, and inspecting OpenAPI documentation.

Bug Fix or Performance Improvement

The Bug

In src/app/stats/Client.tsx, dashboard statistics were updated using a raw setInterval:useEffect(() => {
const id = setInterval(refetch, POLL_MS);
return () => clearInterval(id);
}, [refetch]);

This caused three critical issues:

Overlapping In-Flight Requests (Race Conditions) setInterval fired strictly on a 5-second timer regardless of how long the network request took. If a request stalled or took 6 seconds due to network lag, a second request was fired before the first one finished. This created stacked concurrent requests where an older, delayed response could overwrite newer data in React state.
Backend Hammering During Outages (Thundering Herd) When the backend experienced downtime, high load, or returned errors (500s/429s), the frontend never backed off. It continued hammering the failing endpoint every 5 seconds unabated, causing rate limits and thrashing the UI with re-rendering error alerts.
Timer Churn on Re-render Because refetch was in the dependency array, whenever parent component updates created a new function reference, the old interval was cleared and a new one started from scratch, disrupting regular polling cadence.

How I Fixed It

I replaced setInterval with a custom, lifecycle-aware scheduling hook called useBackoffInterval:

Settled-State Scheduling Instead of a blind clock, the hook waits for the request to settle into either 'success' or 'error' before scheduling the next timer. While a request is in the 'loading' state, no timers run, completely eliminating overlapping requests.
Exponential Backoff on Failures
We track consecutive failures using a ref (failureCountRef). When errors occur, the delay doubles progressively:
```
    ⎛          failures      ⎞
```
delay = min ⎝baseMs × 2 ,maxMs⎠

This increases the retry delay from 5s to 10s, 20s, 40s, and caps at 60s, giving backend services breathing room to recover.

Instant Cadence Recovery On the very first successful response (status === 'success'), the failure counter resets to 0 and the polling interval immediately returns to the standard 5-second cadence without requiring user intervention.
Ref-Stabilized Callback We stored the callback in useRef(callback) and synced it on every render (callbackRef.current = callback). This guarantees that the timer always executes the freshest callback closure without tearing down and restarting the active timer on unrelated UI re-renders.
Clean Unmount Teardown Each scheduled timer returns a cleanup function calling clearTimeout(timeoutId), preventing memory leaks and state updates on unmounted components.

Code

Pull Request / Branch: https://github.com/comzzy-comzzy/Stableroute-frontend/tree/performance/stats-polling-backoff
Target Repository: https://github.com/StableRoute-Org/Stableroute-frontend
Commit: 786106d62e4697aa4a9b536ab75bb320101edd9b (perf(stats): back off polling interval after repeated failures)

// Custom hook in src/app/stats/Client.tsx

export function useBackoffInterval(
status: PollStatus,
callback: () => void,
options: BackoffIntervalOptions = {}
): void {
const {
baseMs = POLL_MS, // 5,000ms
maxMs = MAX_POLL_MS, // 60,000ms
schedule = scheduleTimeout,
cancel = cancelTimeout,
} = options;

const callbackRef = useRef(callback);
const failureCountRef = useRef(0);
callbackRef.current = callback;

useEffect(() => {
// Only schedule next tick after a request settles
if (status !== 'success' && status !== 'error') return;

if (status === 'success') {
  failureCountRef.current = 0;
} else {
  failureCountRef.current += 1;
}

const delayMs =
  status === 'success'
    ? baseMs
    : Math.min(baseMs * 2 ** failureCountRef.current, maxMs);

const timeoutId = schedule(() => callbackRef.current(), delayMs);
return () => cancel(timeoutId);

}, [baseMs, cancel, maxMs, schedule, status]);
}

My Improvements

Custom useBackoffInterval Hook: Instead of hacking state inside the UI component, I decoupled retry scheduling into a reusable, lifecycle-aware hook.
Settled-State Gating: Scheduling only runs when the request status reaches 'success' or 'error'. While the status is 'idle' or 'loading', no timers are scheduled, strictly preventing concurrent in-flight requests.
Deterministic Exponential Backoff with Upper Bound: Consecutive failures increase the delay exponentially (baseMs * 2^failures), progressing from 10s to 20s, 40s, and capping at 60s (maxMs). As soon as an update succeeds, failureCount resets to 0 and normal 5-second polling immediately resumes.
Ref-Stabilized Callback Execution: Storing the refetch callback in a ref (callbackRef.current = callback) prevents timer teardown and re-creation when parent component props change across renders.
Inversion of Control for Deterministic Testing: The hook accepts optional schedule and cancel functions. This allowed writing deterministic unit tests that execute synchronously without flakey time-dependent assertions.
Comprehensive Unit and Integration Test Suite: Added comprehensive test coverage in src/app/stats/page.test.tsx verifying: .Base 5-second cadence on consecutive successful responses. .Delay doubling under network failures up to the 60-second limit. Immediate delay reset to 5 seconds upon recovery. .Prevention of duplicate alert renders during error backoff. .Clean timer cancellation on component unmount.
Contract Documentation: Documented the behavior, parameter options, and lifecycle guarantees in docs/hooks.md.

Best Use of Google AI

Throughout the development, architecture design, debugging, and testing phases of this project and related protocol repositories, I utilized Google Antigravity paired with the Gemini 3.5 Flash (High) model as a primary engineering assistant across multiple tech stacks (React/TypeScript, Rust Soroban, Solidity, and Node.js microservices).

Primary Project: Frontend Exponential Backoff & Lifecycle Safety (Stableroute-frontend) PR / Branch: performance/stats-polling-backoff (Commit 786106d) How Google AI Was Used: Root-Cause Diagnosis: Analyzed client network waterfall logs to isolate why client browsers flooded backend endpoints with requests during API degradation. Gemini 3.5 Flash (High) identified the unmanaged setInterval concurrency hazard. Hook Architecture: Formulated the useBackoffInterval pattern. The model advised storing active callbacks in useRef to prevent timer re-creation on renders while gating execution strictly to settled status states ('success' | 'error'). Deterministic Test Harness: Generated the Jest mock-timer test suite (src/app/stats/page.test.tsx), verifying exact progressive delay doubling (10s, 20s, 40s, 60s cap) and unmount cleanups.