DEV Community: Ujwal Vanjare

Making product recalls executable with Aurora DSQL and Vercel

Ujwal Vanjare — Thu, 25 Jun 2026 03:53:41 +0000

Live demo: https://safestate.vercel.app , code: https://github.com/usv240/safestate

A product recall today is basically a notice. It lives on a webpage, or a PDF, or an email that somebody is supposed to read. Say the problem out loud and it gets uncomfortable fast. A recalled crib can be listed and sold to another family, and nobody in that sale ever sees the recall. Reselling recalled goods is actually illegal, and recalled infant products have killed kids.

I spent this hackathon building something to close that gap. I called it SafeState, and the idea is small: make the recall do something. When a second-hand item is listed or sold, the marketplace checks SafeState first, and recalled units get blocked right at checkout. It is precise down to the serial number, so safe units still sell.

It runs on the stack this hackathon is about. A Next.js front end on Vercel, with Amazon Aurora DSQL behind it.

Why DSQL is the whole point here

The promise SafeState has to keep is this: the moment a recall lands in any region, no marketplace anywhere should ever read that product as "safe" again.

That is a strong consistency problem, not a nice-to-have. If there is any window where a recalled product still looks safe, that is exactly when it gets sold. An eventually consistent store or a nightly sync leaves that window open. DSQL's active-active, multi-region setup with strong consistency is what closes it.

I set up a real peered cluster across us-east-1 and us-east-2, with us-west-2 as the witness. Write a recall through one region's endpoint and you can read it back from the other region right away. There is a page in the app that lets you run that yourself.

The one trick that makes it work

DSQL runs on snapshot isolation (PostgreSQL REPEATABLE READ) with optimistic concurrency. It catches write-write conflicts at commit time. Snapshot isolation will not protect you from write skew, so I had to design around that.

To guarantee that a recall and a sale of the same product actually collide, I make both of them write the same row. Every model has one safety_guard row that holds its status and an epoch number.

// authorize-transfer, simplified. The AUTHORIZED path touches the SAME guard
// row a concurrent recall writes, so DSQL is forced to detect the conflict.
await client.query("BEGIN");
await client.query("SELECT epoch FROM safety_guard WHERE model_id = $1", [modelId]);

// ...evaluate every active directive against THIS unit's serial...
// if it is covered, return BLOCKED. otherwise:

await client.query("INSERT INTO ownership_transfers (...) VALUES (...)");
await client.query("UPDATE product_instances SET current_owner_id = $1 WHERE id = $2", [buyer, id]);
await client.query("UPDATE safety_guard SET updated_at = now() WHERE model_id = $1", [modelId]); // the conflict-forcing write
await client.query("COMMIT"); // the loser throws SQLSTATE 40001 / OC000 here

If the recall commits first, the sale's COMMIT throws SQLSTATE 40001 (OC000). A small wrapper catches it, backs off with some jitter, and runs the whole transaction again. The second time around it reads the recalled state and returns BLOCKED. So there is no version of events where a recalled product slips through as safe.

const RETRYABLE = new Set(["40001", "OC000", "OC001"]);
// retry the WHOLE transaction on conflict, backoff plus jitter, max 3 attempts

Proving it under load

A guarantee you cannot see is just a claim, so I put a stress test right in the app: a hundred concurrent attempts to buy a recalled unit, fired at the live cluster at once. Every one comes back blocked. Zero recalled units sell, no matter the concurrency.

Getting there taught me something. My first version put a SELECT ... FOR UPDATE on the guard row in every check. That was overkill. Two blocked checks on the same model would each take a write intent on that one row and conflict with each other for no reason. The conflict I actually care about is between a recall and an authorized sale, and both of those already write the guard row. So I dropped the FOR UPDATE from the read. The blocked path stopped fighting itself, the load test went clean, and the recall versus sale conflict still fires exactly as before.

Two databases, on purpose

Not everything belongs in the transactional store. Every public check, verify, and scan is an event worth counting, and every Safety Receipt is a small durable record. That stream is write-heavy and key-accessed, and it does not need a distributed transaction. So it lives in Amazon DynamoDB, while Aurora DSQL keeps the transactional core. Picking the right database per workload, instead of forcing one to do both, kept the hot path clean.

The Vercel side

Route handlers talk to DSQL over the normal Postgres protocol, but auth is a short-lived IAM token minted per connection with @aws-sdk/dsql-signer. There is no database password sitting in an env var anywhere.

A Vercel Cron job pulls real recalls from the public CPSC API once a day. And Claude reads messy second-hand listings, the kind a person actually writes ("used baby sleeper, works fine"), and figures out which recall they match, with a confidence score. The uncertain ones go to a review queue instead of being auto-blocked.

Two more things the same app does. When a recall is issued, it walks live ownership and emails the people who own one now, not the original buyers. And the public check fans out to CPSC, FDA, and NHTSA at once, so you can look up a product, a bag of spinach, or a car.

One thing that cost me an hour. Vercel functions run on Lambda, and Lambda reserves AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and AWS_REGION. You cannot set those as env vars. So I pass the DSQL credentials under different names and hand them to the signer directly.

const creds = process.env.SAFESTATE_AWS_ACCESS_KEY_ID
  ? { accessKeyId: process.env.SAFESTATE_AWS_ACCESS_KEY_ID, secretAccessKey: process.env.SAFESTATE_AWS_SECRET_ACCESS_KEY }
  : undefined; // local dev falls back to the default AWS provider chain
const signer = new DsqlSigner(creds ? { hostname, region, credentials: creds } : { hostname, region });

A few things that helped

If you build on DSQL, pick a problem where being correct under concurrency is the actual product, not a side detail. That is where it earns its keep. Make your conflicting operations write the same row so OCC has something to catch. And write the retry-on-40001 wrapper before anything else, because you will lean on it constantly.

Recalls should stop being PDFs and start being decisions. Aurora DSQL and Vercel got me there over a weekend.

Live: https://safestate.vercel.app , code: https://github.com/usv240/safestate

I built this for the H0: Hack the Zero Stack hackathon. #H0Hackathon

I built a GitLab flow that tells you what a diff actually means

Ujwal Vanjare — Mon, 22 Jun 2026 23:08:24 +0000

Every code review starts the same way. You open a diff and try to figure out
what it actually means - not just what changed, but what depends on it,
whether it breaks something downstream, and whether someone else is about to
step on the same code. That investigation usually falls on the reviewer,
by hand, every single time.

I spent the last two weeks building something to change that.

What I built

Orbit Change Passport is a GitLab Duo Agent Platform flow that fires
automatically when a merge request is marked ready for review. It queries
GitLab Orbit's Knowledge Graph and posts a structured comment before anyone
reads a single line of the diff.

Here is what the comment covers:

Changed Surface - the exact functions and methods the diff touched, identified by name, not line numbers
Dependency graph - a live Mermaid diagram of everything that imports the changed modules, rendered inline in GitLab
Conflict Radar - every other open MR right now that touches the same code, caught before merge instead of at it
Cross-project blast radius - files in other projects in the group that depend on what changed. This one is only possible because Orbit's graph spans the whole group, not just one repo
Test gaps - test files that import the changed module but were not touched in this MR
Suggested reviewers - based on recent authorship of dependent files
Reviewer Brief - a second shorter comment posted immediately after: one paragraph with the single most important thing before reading the diff

A companion Duo Chat agent lets reviewers keep asking questions against the
same graph after the passport posts - "what else calls this?",
"who imports this file?" - answered live, not restated from the comment.

A concrete example

Here is what the impact line looks like on a real run:

Impact: HIGH - 2 definitions changed - 2 within-project dependents -
cross-project blast radius (3 projects) - 1 conflict

That single line tells me: this change has dependents outside this repo,
and another open MR is already touching the same functions. Both of those
things would normally take 10 minutes to find manually. They showed up
automatically before I opened the diff.

The cross-project result is the one that surprised me most. A docstring
change to engine/orbit_client.py surfaced 14 dependent files across three
other projects in the group. Nobody catches that by scrolling through a diff.

How it works

The flow uses a three-tier strategy to identify which functions a diff
actually touched:

DEFINES traversal in the Orbit graph (File to Definition edge)
fqn-fragment query as a fallback for Rust crates
Bounded page scan as a last resort

Each tier produces a different confidence level in the output. This redundancy
matters because query availability on the live Orbit instance is not guaranteed.
DEFINES, IMPORTS, CALLS, and Definition filtering have each independently been
unavailable within a two-hour window during testing. A flow that only works
when one specific query is live is not useful.

For dependents, the flow runs ImportedSymbol lookups in both FQN and
crate-relative forms for Rust, and by identifier_name stem for Python files.
That last one took a while to figure out. Python relative imports
(from . import module) are stored in Orbit with import_path set to the
package name and identifier_name set to the module stem, not as a dotted
path. We found that by reading the actual graph data.

The Reviewer Brief is a second call to create_merge_request_note within the
same agent turn. We arrived at this after two other approaches failed: a
router-chained second AgentComponent that never started, and a second ambient
flow that turned out to share the trigger silently with the first. Only the
most-recently-enabled one fires - that was not documented anywhere and took a
while to diagnose.

What is in the repo

flows/change-passport/change-passport.yaml   - the Duo Agent Platform flow
skills/ask-orbit-passport/SKILL.md           - companion Duo Chat agent
engine/passport_runner.py                    - CLI runner, posts to any MR
engine/orbit_client.py                       - Orbit query layer
research/findings.md                         - every query pattern confirmed
                                               against the live graph

Try it

The flow is live in the AI Catalog. The repo is public and MIT licensed.

Built for the GitLab Transcend Hackathon.

A diff shows what changed. Orbit Change Passport shows what that change means.

Scaling Astrolord: Our Journey with Serverless on AWS

Ujwal Vanjare — Wed, 04 Feb 2026 03:23:53 +0000

When we started building Astrolord, we knew we had a tricky engineering problem on our hands. We were building an AI-powered astrology platform that needed to perform heavy astronomical calculations one second and stream personalized AI responses the next. We needed infrastructure that could handle a sudden spike in traffic, like during a major planetary transit, without burning a hole in our pocket during quiet hours.

We decided early on to go all-in on AWS Serverless. It wasn't just about avoiding server management; it was about building an architecture that could scale to zero when no one was using it, and scale up infinitely when they were. Here is a look at how we pieced it all together.

The Compute Layer: AWS Serverless

The heart of our backend is Python. The challenge was deploying our application in a way that didn't require maintaining a fleet of servers or paying for idle time.

We chose AWS Lambda for its efficiency. By adapting our web application to run in a serverless environment, we can write modern, clean code while letting AWS handle the underlying infrastructure.

There were trade-offs, of course. We had to be careful with "cold starts", the initial delay when a function wakes up. We spent time optimizing our application startup to keep latency minimal. But the benefit of paying literally zero dollars when no traffic is hitting the API made it an easy choice.

The Front Door: API Gateway

Sitting in front of those Lambda functions is Amazon API Gateway. Connective tissue is often overlooked, but for us, this piece is critical. It acts as our secure entry point, routing requests to the correct backend services.

Beyond just routing, we rely on it for stability. We configured usage plans and throttling rules directly at the gateway level. This means if a bad actor tries to hammer our API, AWS blocks them before they even wake up our compute layer, saving us money and processing power.

Delivering the UI: S3 and CloudFront

For the frontend, we built a static React application. We didn't want to run a web server or manage containers just to serve HTML and JavaScript files.

Instead, we use what I consider the "gold standard" for static hosting: Amazon S3 paired with CloudFront. We upload our build artifacts into an S3 bucket, which offers incredible durability. Then, CloudFront sits in front of that bucket, caching our application at edge locations all over the world.

The result is that a user in Mumbai loads the app just as fast as a user in New York. We also configured strict security controls, ensuring that no one can bypass the CDN to hit our bucket directly.

Observability

One thing they don't tell you about distributed systems is that debugging can be a nightmare if you aren't prepared. Since we don't have a single server to SSH into, we rely heavily on centralized logging and monitoring.

We capture all standard output from our functions into CloudWatch Logs. We also set up specific metric filters to track errors and throttling events. If our error rate crosses a certain threshold, an alarm triggers and we get notified immediately. It gives us the confidence to deploy on a Friday (well, almost).

The Economics of Serverless

One of the biggest wins for us wasn't just technical, it was financial.

With a traditional EC2 or container-based architecture, you are paying for capacity 24/7. Even if no one visits your site at 3 AM, that server is still running, and you are still receiving a bill.

With this serverless setup, our infrastructure cost aligns perfectly with our business growth.

Zero Idle Costs: When our app is quiet, our compute bill is literally $0.
Generous Free Tier: AWS offers a substantial free tier for Lambda and API Gateway, meaning we effectively run our development and testing environments for free.
No Over-Provisioning: We never have to guess how many servers we need. The system just scales to meet demand, whether that's 5 users or 5,000.

Why This Architecture Works for Us

Usage patterns in our app are unpredictable. Some days are quiet; other days, everyone wants to know what the full moon means for them.

This serverless architecture on AWS absorbs that volatility perfectly. We don't have to provision for peak capacity and pay for idle time. We just pay for the milliseconds of compute we actually use. It has allowed us to focus less on "keeping the lights on" and more on improving the actual product.

Time-Travel Debugging for Python: A Complete Tutorial

Ujwal Vanjare — Fri, 23 Jan 2026 05:10:45 +0000

Time-Travel Debugging for Python: A Complete Tutorial

Building web applications means dealing with external APIs, databases, and the inevitable production bugs. I'm going to show you how to capture production issues and debug them locally without ever hitting those external services again.

This is a complete walkthrough using Timetracer with a Starlette application. By the end, you'll have a working example and understand how to apply this to your own projects.

Note: If you're new to Timetracer, you might want to check out my initial post about why I built this tool, or the v1.4 release post covering Django and pytest integration.

This tutorial focuses specifically on Starlette integration and shows the complete debugging workflow with the new v1.6.0 dashboard features.

The Problem

You know that moment when a bug happens in production? You spend hours trying to reproduce it locally. You're making API calls to third-party services, dealing with rate limits, stale data, and that nagging feeling you're not testing the exact scenario that failed.

Traditional debugging flow:

Bug reported in production
Try to reproduce locally (often fails)
Add logging and redeploy (slow)
Hope you captured enough context (usually didn't)
Repeat until fixed (hours or days)

There's a better way. With Timetracer, you capture the entire request context in production and replay it locally. Think of it as a flight recorder for your web application.

Setting Up the Project

Let's build a simple API that proxies GitHub user data. First, install the dependencies:

pip install starlette uvicorn httpx timetracer

Create a file called app.py:

from starlette.applications import Starlette
from starlette.routing import Route
from starlette.responses import JSONResponse
import httpx

async def homepage(request):
    return JSONResponse({
        "message": "Welcome to the Starlette + Timetracer example",
        "endpoints": ["/", "/user/{username}", "/repos/{username}"]
    })

async def get_user(request):
    username = request.path_params["username"]
    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.github.com/users/{username}")
        return JSONResponse(response.json())

async def get_repos(request):
    username = request.path_params["username"]
    async with httpx.AsyncClient() as client:
        user_resp = await client.get(f"https://api.github.com/users/{username}")
        user_data = user_resp.json()

        repos_resp = await client.get(f"https://api.github.com/users/{username}/repos")
        repos = repos_resp.json()

    return JSONResponse({
        "username": username,
        "total_repos": user_data["public_repos"],
        "top_repos": [{"name": r["name"], "stars": r["stargazers_count"]} 
                      for r in sorted(repos, key=lambda x: x["stargazers_count"], reverse=True)[:5]]
    })

app = Starlette(debug=True, routes=[
    Route("/", homepage),
    Route("/user/{username}", get_user),
    Route("/repos/{username}", get_repos),
])

This gives us three endpoints: a homepage, a user lookup, and a repo list. The last two hit the GitHub API.

The Starlette application with three endpoints

Integrating Timetracer

Now add Timetracer. Import the integration and call auto_setup():

from timetracer.integrations.starlette import auto_setup

# ... your routes ...

app = Starlette(debug=True, routes=[
    Route("/", homepage),
    Route("/user/{username}", get_user),
    Route("/repos/{username}", get_repos),
])

# This is the only line you need for Timetracer
auto_setup(app, plugins=["httpx"])

That's it. One line of code. This adds middleware that captures every request and tracks all httpx calls to external APIs.

Recording Requests

Start the server in record mode:

export TIMETRACER_MODE=record
uvicorn app:app --reload

Your terminal should show Timetracer capturing requests:

Terminal output showing Timetracer recording requests with timing information

Now let's make some requests and see what gets captured.

Request 1: Homepage

curl http://localhost:8000/

Response:

{
  "message": "Welcome to the Starlette + Timetracer example",
  "endpoints": ["/", "/user/{username}", "/repos/{username}"]
}

Browser showing the homepage JSON response

Terminal output:

timetracer [OK] recorded GET /  id=cddb  status=200  total=9ms  deps=none
  cassette: cassettes/2026-01-23/GET__root__cddb6be9.json

Notice deps=none because this endpoint doesn't make any external calls.

Request 2: User Lookup

curl http://localhost:8000/user/octocat

Response:

{
  "login": "octocat",
  "name": "The Octocat",
  "bio": null,
  "public_repos": 8,
  "followers": 21594
}

GitHub user data returned through our API

Terminal output:

timetracer [OK] recorded GET /user/octocat  id=88d7  status=200  total=472ms  deps=http.client:1
  cassette: cassettes/2026-01-23/GET__user_octocat__88d76871.json

This time deps=http.client:1 shows one external HTTP call was tracked. The duration is 472ms instead of 9ms because we're waiting for GitHub's API.

Request 3: Repository List

curl http://localhost:8000/repos/octocat

Top repositories for the octocat user

This endpoint makes two GitHub API calls: one for the user data and one for the repository list.

What Got Saved?

Each cassette is a JSON file containing your request, response, and all external dependencies with timing information.

Cassette file showing the captured request, response, and external API calls

The cassette includes:

Request details (method, path, headers, body)
Response details (status, headers, body, duration)
All external dependencies (each GitHub API call with its own timing)
Metadata about the session (framework, timestamp, etc.)

Using the Dashboard

Now for the interactive part. Timetracer includes a web dashboard to browse and analyze your captured requests.

Start the dashboard server:

timetracer serve --dir cassettes --port 3000

Open http://localhost:3000 in your browser:

Dashboard showing all captured requests with statistics

The dashboard shows:

Total requests, success count, error count
Every captured request with method, path, status, duration, and dependencies
Search and filter capabilities
View details or replay any request

Viewing Request Details

Click "View" on the /repos/octocat request:

Detailed view showing request, response, and external API dependencies

The detail view shows:

Request metadata: Path, method, timestamp
Response: Status 200, duration 524ms
Dependency Events: Both GitHub API calls with individual timings
- GET https://api.github.com/users/torvalds (104ms)
- GET https://api.github.com/users/torvalds/repos (95ms)
Ready-to-use replay command

This view tells you exactly what happened during the request, including all external services that were called.

Filtering Requests

Type "repos" in the search box:

Dashboard filtered to show only repository-related requests

The dashboard now shows "Showing 5 of 19 cassettes" with only the matching requests visible.

You can also filter by HTTP method or status code to focus on specific types of requests.

Inspecting the Raw Data

For technical inspection, the dashboard includes a Raw JSON viewer:

Raw JSON view showing the complete cassette structure

This gives you direct access to the underlying cassette data, making it easy to verify exactly what state is being captured and will be replayed.

Debugging a Real Bug

Now let's use Timetracer for what it's really good at: debugging production issues without touching production.

The Bug Appears

Imagine a user reports that requesting a non-existent GitHub user crashes the server with a 500 error. The problematic code:

async def get_user(request):
    username = request.path_params["username"]
    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.github.com/users/{username}")
        return JSONResponse(response.json())  # Crashes on 404

When someone requests a user that doesn't exist, GitHub returns 404, but our code assumes success and tries to parse the error response.

Even though the app crashes, Timetracer still captures the request:

timetracer [ERROR] recorded GET /user/nonexistent-user-12345  id=bad1  status=500  total=156ms  deps=http.client:1
  cassette: cassettes/2026-01-23/GET__user_nonexistent-user-12345__bad1234.json

Inspecting the Error

In the dashboard, click "View" on the failed request:

Dashboard detail view showing a 404 error from GitHub API

The detail view clearly shows that GitHub returned a 404, which propagated to our endpoint as a 500 error. You can see exactly what happened: the external API call failed, and our code didn't handle it properly.

The Fix

Looking at the dashboard detail view, you can see GitHub returned 404. Fix the code:

async def get_user(request):
    username = request.path_params["username"]

    async with httpx.AsyncClient() as client:
        response = await client.get(f"https://api.github.com/users/{username}")

        # Check status code before parsing
        if response.status_code == 404:
            return JSONResponse(
                {"error": "User not found"},
                status_code=404
            )

        return JSONResponse(response.json())

Getting the Replay Command

The dashboard provides a ready-to-copy replay command:

Ready-to-use replay command for testing the fix

Just copy this command to test your fix with the exact scenario that failed in production.

Testing the Fix Without Network

This is where Timetracer shows its real value. You can test the fix using the captured cassette without making any real API calls to GitHub.

Stop the server and restart in replay mode:

export TIMETRACER_MODE=replay
export TIMETRACER_CASSETTE=cassettes/2026-01-23/GET__user_nonexistent-user-12345__bad1234.json
uvicorn app:app --reload

Server running in replay mode with mocked external API responses

Make the same request:

curl http://localhost:8000/user/nonexistent-user-12345

Terminal shows:

timetracer replay GET /user/nonexistent-user-12345  mocked=1  matched=OK  runtime=5ms

Response:

{
  "error": "User not found"
}

Status: 404

The fix works. Notice:

No network call - the response came from the cassette
Fast: 5ms instead of the original 156ms
Exact scenario: Same 404 from GitHub that caused the original crash
Offline: This works with no internet connection

You just debugged and fixed a production bug without touching production or making a single external API call.

Performance Comparison

Let's compare the timing differences:

Record Mode vs Replay Mode

Endpoint	Record Duration	Replay Duration	Speedup
`/`	9ms	8ms	1.1x
`/user/octocat`	472ms	8ms	59x faster
`/repos/octocat`	524ms	10ms	52x faster

Comparison of request durations in record mode versus replay mode

For endpoints without external calls, the times are similar. But anything that touches an external API or database becomes dramatically faster in replay mode.

This isn't just about speed. It's about reliability. Tests that depend on external APIs can be flaky due to network issues, rate limiting, or changing data. Replay mode eliminates all those problems.

When to Use This

I've found Timetracer most useful in these scenarios:

1. Debugging Production Bugs

When a user reports an issue, capture the failing request in production. Download the cassette and debug locally with the exact same conditions. No need to reproduce complex scenarios or guess at what data caused the problem.

2. Integration Testing

Tests that hit real APIs are slow and unreliable. Record your test scenarios once, then replay them. Tests run in milliseconds instead of seconds, and they never fail due to network issues or rate limiting.

3. Offline Development

Working on a plane or anywhere without internet? Load up cassettes with the API responses you need. Everything works normally without network access.

4. Performance Analysis

The dashboard shows you exactly how long each external dependency takes. If your endpoint is slow, you can see whether it's your code or a slow external API.

5. Preventing Regressions

When you fix a bug, keep the cassette and add it to your test suite. That specific scenario is now covered forever.

Framework Support

Timetracer works with:

Supported web frameworks and external service integrations

Web Frameworks:

FastAPI
Starlette (new in v1.6.0)
Flask
Django

External Services:

httpx and requests (HTTP clients)
Motor and PyMongo (MongoDB)
SQLAlchemy (SQL databases)
Redis

The integration is similar across all frameworks. Usually just auto_setup(app) or adding middleware.

Trade-offs to Consider

Storage: Each cassette is a JSON file. If you have many unique requests, you'll accumulate files. Clean up old cassettes periodically or store them in S3.

Sensitive data: Cassettes contain your actual request and response data. Review what's being captured, especially in production. Timetracer has built-in redaction for common sensitive fields like passwords and tokens, but verify this for your use case.

Cassette maintenance: API responses change over time. You'll need to re-record cassettes when your external dependencies change their response format.

Not a replacement: This isn't trying to replace your testing framework or mocking library. It's a debugging tool that captures production context and lets you work with it locally.

Getting Started

Install Timetracer:

# For Starlette
pip install timetracer[starlette]

# For FastAPI
pip install timetracer[fastapi]

Integrate into your app:

from timetracer.integrations.starlette import auto_setup
auto_setup(app, plugins=["httpx"])

Run in record mode:

export TIMETRACER_MODE=record
uvicorn app:app

View the dashboard:

timetracer serve --dir cassettes --port 3000

Test in replay mode:

export TIMETRACER_MODE=replay
export TIMETRACER_CASSETTE=path/to/cassette.json
uvicorn app:app

Conclusion

The workflow I showed here - capturing a failing production request, viewing it in the dashboard, fixing the bug, and testing the fix in replay mode - saves hours compared to traditional debugging.

Instead of:

Trying to reproduce the bug
Adding logging
Redeploying
Hoping you captured enough context
Repeating until fixed

You can:

Download the cassette
View it in the dashboard
Fix the code
Verify the fix in replay mode
Deploy with confidence

The complete example code is on GitHub at github.com/usv240/timetracer. All 174 tests are passing, and version 1.6.0 just added Starlette support and PyMongo integration.

If you work with external APIs, spend time debugging production issues, or want faster integration tests, give it a try.

Resources

GitHub: https://github.com/usv240/timetracer
PyPI: https://pypi.org/project/timetracer
Documentation: GitHub README
Example code: See examples/starlette_example/ in the repo

Tags: #python #starlette #fastapi #debugging #testing #devtools

Timetracer v1.4: Native Django Support and Easiest pytest Integration

Ujwal Vanjare — Mon, 19 Jan 2026 18:32:01 +0000

A few weeks ago, I introduced Timetracer in my previous post: "I Got Tired of 'It Works on My Machine' So I Built a Time-Travel Debugger".

The tool allows you to record API interactions (including dependencies like databases and external APIs) and replay them locally to debug production issues.

The initial version focused on FastAPI and Flask. However, the most frequent feedback I received was the need for Django support and better integration with pytest suites.

I just released v1.4.0, which adds both.

Here is why this matters and how it works.

Why This Matters

1. No More "Enterprise Setup" Pain

Django is often used for large, mature applications. These apps tend to have complex dependencies, specific database states, VPN-locked APIs, or legacy SOAP services that are a pain to run locally.

With Timetracer's new middleware, you can record a session from a staging environment (or a colleague's machine that actually works) and replay it on your machine. You get the full app behavior without needing the full enterprise infrastructure running on localhost.

2. Tests That Don't Lie

We've all written tests with unittest.mock where we guess what the API returns. Then the API changes, our mock stays the same, the test passes, but production breaks.

The new pytest integration replaces brittle mocks with real, recorded interactions. Your tests run against actual data snapshots, making them far more reliable than manual mocks.

Django Support

Timetracer now includes middleware that works with Django 3.2 LTS and newer. It supports both standard synchronous views and the newer async views in Django 4.1+.

The integration captures:

Incoming HTTP requests
Outbound API calls (requests, httpx, aiohttp)
Database queries (via SQLAlchemy for now, native ORM soon)
Redis operations

Setting it up

First, install the package with Django dependencies:

pip install timetracer[django,requests]

Then add the middleware in your settings.py. It usually works best near the top of the list so it can capture everything:

# settings.py

MIDDLEWARE = [
    'timetracer.integrations.django.TimeTracerMiddleware',
    # ... other middleware
]

# Optional configuration
TIMETRACER = {
    'MODE': 'record',  # 'record', 'replay', or 'off'
    'CASSETTE_DIR': './cassettes',
}

If your app makes external API calls, you should enable the plugins in your AppConfig or settings.py:

# myapp/apps.py or settings.py
from timetracer.integrations.django import auto_setup

# Enable recording for the requests library
auto_setup(plugins=['requests'])

Workflow

Run your server: python manage.py runserver
Browse your site. Timetracer saves JSON "cassettes" for each request.
To debug a specific request later, restart with TIMETRACER_MODE=replay.
The server will now mock all external calls using the recorded data.

pytest Integration

Previously, using recorded cassettes in tests required manual setup. v1.4.0 adds a pytest plugin that automatically registers fixtures when you install the package.

This allows you to write integration tests that don't need live external APIs but still exercise your full stack.

Using the Fixtures

The plugin provides three main fixtures:

1. timetracer_replay
Use this to run a test against a pre-recorded session. It guarantees the test runs exactly the same way every time.

def test_user_profile(timetracer_replay, client):
    # 'user_profile.json' contains the recorded interaction
    with timetracer_replay("cassettes/user_profile.json"):
        response = client.get("/api/users/123")
        assert response.status_code == 200
        assert response.json()['username'] == 'testuser'

2. timetracer_record
Use this when writing a new test case. It captures the interaction so you can save it as a cassette.

def test_new_feature(timetracer_record, client):
    # This will execute real network calls and save the result
    with timetracer_record("cassettes/new_feature.json"):
        response = client.get("/api/new-feature")
        assert response.status_code == 200

3. timetracer_auto
This is useful for TDD. If the cassette doesn't exist, it records. If it does exist, it replays.

def test_checkout_flow(timetracer_auto, client):
    # Records first time, replays subsequently
    with timetracer_auto("cassettes/checkout.json"):
        response = client.post("/api/checkout", {'cart_id': 'abc'})
        assert response.status_code == 200

Async Support (aiohttp)

We also added a plugin for aiohttp. Building high-concurrency apps often requires async HTTP clients, and aiohttp is a popular choice alongside httpx.

Timetracer now correctly intercepts and records aiohttp.ClientSession requests, capturing the full async flow.

What's Next

The goal remains effective local debugging. If you are using Django or pytest, I'd appreciate you trying this out and letting me know if it helps simplify your debugging workflow.

Repositories and Docs:

GitHub: https://github.com/usv240/timetracer
PyPI: pip install timetracer

I Got Tired of "It Works on My Machine" So I Built a Time-Travel Debugger

Ujwal Vanjare — Sun, 18 Jan 2026 06:17:35 +0000

Last year, I spent three hours debugging a checkout bug that only happened in production. The external payment API was returning a slightly different response format than what we saw in staging. By the time I figured it out, I'd burned half my day and my patience.

That was the last straw.

I started building Timetracer that weekend. Now, when something breaks in production, I can capture the exact request, complete with every external API call, database query, and cache operation, and replay it on my laptop. No more guessing. No more "can you add some logging and redeploy?"

This post is about why I built it, how it works, and why you might want to use it too.

The Debugging Problem Nobody Talks About

Here's a scenario you've probably lived through:

A customer reports that their order failed. You check the logs. You see the error. You try to reproduce it locally. But your local setup hits a different database, a sandbox payment API, and your Redis is empty. The bug doesn't happen.

You add more logging. Redeploy. Wait for it to happen again. Check the new logs. Still can't reproduce it. Repeat.

Or maybe you're working on a feature that integrates with a third-party API, but that API is rate-limited, or requires special credentials, or just goes down at random times. Every time you run your code, you're making real API calls. Testing becomes painful.

Or you're trying to demo something to your team, but the staging environment is down. Or slow. Or someone else is testing migrations on it.

These problems have something in common: your code depends on things outside your control, and that makes debugging and development unpredictable.

What If You Could Record Everything?

The idea behind Timetracer is simple: when your API handles a request, record everything that happens. Not just the request and response, but every external call your code makes.

That HTTP call to Stripe? Recorded.
That SELECT query to Postgres? Recorded.
That Redis GET? Recorded.

All of it goes into a JSON file we call a "cassette" (borrowing the term from VCR.py, which does something similar but only for HTTP).

Later, when you want to debug, you load that cassette and replay the request. Timetracer intercepts all the external calls and returns the recorded responses instead of making real ones.

Same input. Same external responses. Same bug. But now it's on your laptop, where you can step through the code, add breakpoints, and actually figure out what went wrong.

How It Actually Works

Let's get into the technical stuff.

Setup

If you're using FastAPI, adding Timetracer is two lines:

from fastapi import FastAPI
from timetracer.integrations.fastapi import auto_setup

app = auto_setup(FastAPI())

That's it. The auto_setup function adds middleware that handles recording and replaying.

For Flask, it's similar:

from flask import Flask
from timetracer.integrations.flask import auto_setup

app = auto_setup(Flask(__name__))

You control the behavior with environment variables:

# Record mode - captures everything
export TIMETRACER_MODE=record
export TIMETRACER_DIR=./cassettes

python app.py

Now make some requests to your app. Each request creates a cassette file.

What's In a Cassette?

Here's a simplified version of what gets saved:

{
  "request": {
    "method": "POST",
    "path": "/checkout",
    "body": {"cart_id": "abc123", "user_id": "user_456"}
  },
  "response": {
    "status": 200,
    "body": {"order_id": "order_789"},
    "duration_ms": 342
  },
  "events": [
    {
      "type": "http.client",
      "method": "POST",
      "url": "https://api.stripe.com/v1/charges",
      "request_body": {"amount": 2999, "currency": "usd"},
      "response_body": {"id": "ch_xxx", "status": "succeeded"},
      "duration_ms": 187
    },
    {
      "type": "db.query",
      "query": "INSERT INTO orders (user_id, total) VALUES (?, ?)",
      "params": ["user_456", 29.99],
      "duration_ms": 12
    }
  ]
}

Everything is there. The incoming request, the outgoing response, and every dependency call in between.

Replaying

To replay, point Timetracer at the cassette:

export TIMETRACER_MODE=replay
export TIMETRACER_CASSETTE=./cassettes/checkout_abc123.json

python app.py

Now when you hit /checkout with the same request, Timetracer intercepts the Stripe call and the database query. Instead of making real calls, it returns the recorded responses.

Your code runs exactly as it did in production, but locally, without needing Stripe credentials or a production database.

The Plugins

Recording HTTP calls is useful, but real applications do more than HTTP. That's why Timetracer has plugins for common dependencies.

HTTP Clients

We support both httpx (async and sync) and the requests library:

from timetracer.plugins import enable_httpx, enable_requests

enable_httpx()    # For httpx calls
enable_requests() # For requests library calls

Databases

SQLAlchemy queries get captured with their SQL and parameters:

from timetracer.plugins import enable_sqlalchemy

engine = create_engine("postgresql://...")
enable_sqlalchemy(engine)

Caching

Redis commands are recorded too:

from timetracer.plugins import enable_redis

enable_redis()

When you replay, all of these return the recorded values. No real database connections. No real Redis. No real HTTP calls. Just the data from the cassette.

The Dashboard

After using Timetracer for a few weeks, I got tired of opening JSON files to find the cassette I needed. So I built a dashboard.

timetracer serve --dir ./cassettes --open

This starts a local web server with a table of all your cassettes. You can:

Sort by time, method, status, or duration
Filter by endpoint, HTTP method, or status code
Click a row to see full details
View the dependency timeline
See the raw JSON
Replay directly from the browser

Error responses show up with red highlighting, and slow requests (>1 second) get a warning indicator. If a request threw an exception, you see the full Python stack trace.

It's nothing fancy, just a single HTML file with some JavaScript, but it makes browsing through cassettes way faster than grepping through JSON.

Dealing With Sensitive Data

Early on, I realized that cassettes could contain passwords, API keys, and other stuff I definitely didn't want in my Git repo.

So Timetracer automatically redacts sensitive data:

Headers that get stripped:

Authorization
Cookie
Set-Cookie
X-API-Key
And about 20 others

Body fields that get masked:

password, secret, token
credit_card, cvv, ssn
api_key, private_key
And about 100 more patterns

In the latest release (v1.2.0), I added pattern detection for PII, emails, phone numbers, Social Security numbers, credit card numbers. The credit card detection even validates the Luhn checksum to avoid false positives.

A value like user@example.com becomes [REDACTED:EMAIL]. A credit card number becomes [REDACTED:CREDIT_CARD].

The goal is that cassettes should be safe to commit without thinking too hard about what's in them.

Real Use Cases

Debugging Production Bugs

This is the original reason I built it. Something breaks in production, you grab the cassette, replay locally, and debug with full context.

Regression Testing

Once you fix a bug, that cassette becomes a test case. You know exactly what input caused the problem and what the correct behavior should be. Run it against future code changes to make sure the bug doesn't come back.

Offline Development

Working on a flight? At a coffee shop with bad WiFi? If you have cassettes from previous sessions, you can keep developing without hitting real APIs.

Demos

Recording demo scenarios means your demos work even when external services are flaky. No more "let me refresh that" during a presentation.

Performance Analysis

The timeline command generates a waterfall chart showing how long each dependency took:

timetracer timeline ./cassette.json --open

You can see exactly where time is being spent. Is it the database query? The third-party API? The Redis lookup? It's all right there.

What About VCR.py?

VCR.py is great. I've used it for years. But it only records HTTP calls.

In a typical web application, a single API request might:

Query the database for user info
Call an external API for pricing
Check a cache for recent activity
Write to another database
Make another API call

VCR.py captures step 2 and 5. The rest? You're on your own.

Timetracer captures all of it. One cassette has everything.

Also, VCR.py is designed for test suites, you decorate individual test functions. Timetracer is designed as middleware. Every request through your app can be recorded. That makes it useful for production debugging, not just testing.

Getting Started

Install with pip:

pip install timetracer[fastapi,httpx]

Or for Flask:

pip install timetracer[flask,requests]

Add the middleware, set the environment variables, and make some requests. Your first cassettes will be in the directory you specified.

The documentation has more details on configuration, the CLI tools, S3 storage, and all the other features I didn't cover here.

GitHub: https://github.com/usv240/timetracer

What's Next

I'm using Timetracer on my own projects, and I keep finding things to improve. Some ideas on the roadmap:

Better support for async database drivers
GraphQL request parsing
Request diffing between cassettes
Maybe a VS Code extension?

If you try it out and have feedback, bugs, feature requests, or just thoughts, I'd love to hear it. Open an issue on GitHub or reach out on LinkedIn.

Thanks for reading. I hope Timetracer saves you some debugging time.

Links:

GitHub: https://github.com/usv240/timetracer
PyPI: https://pypi.org/project/timetracer/