DEV Community: Kavya

I kept hitting Supabase errors, so I built a scanner for the legacy API key deprecation published: false

Kavya — Mon, 28 Sep 2026 19:09:15 +0000

I've been using Supabase as a backend for several months. Most of that time went into errors. Something would break, and I'd end up changing my setup until it worked again. At some point I got curious about what problems other developers were hitting, so I spent a week just researching them before writing any code.

One problem stood out because it has a deadline. Supabase is replacing its legacy JWT-based anon and service_role keys with new sb_publishable_ and sb_secret_ keys. Projects created after November 2025 don't get legacy keys, and Supabase's docs say the legacy keys are planned for removal by the end of 2026. Every old tutorial, Stack Overflow answer and copied .env.example still uses the old names.

Why this isn't a find and replace

A legacy key reference can mean two very different things. A service_role key in a server-side file is a migration task. The same key reachable from client code is an emergency, because it bypasses row level security and can end up in the browser. So the tool has to classify what it finds, not just search for it.

What I built

supabase-migrate-doctor is a CLI (and an MCP server) that scans a codebase:

pip install -e .
supabase-migrate scan ./path/to/repo

It looks for legacy key literals, legacy env var names, and keys that are already migrated. Each finding gets a level:

CRITICAL: privileged key reachable from client code
HIGH: privileged key, server-side
MEDIUM: anon key
INFO: already migrated

It exits non-zero on HIGH or above, so it can gate CI.

I did not want to trust a general chatbot for the explanations. A model's training data probably treats the old key system as the correct one, so it can give confident but wrong migration advice. Instead, every explanation is grounded in a small knowledge base of Supabase's own docs, with the source URL attached. There are two modes. The default is an offline template that needs no setup. If you set a Groq or Gemini key, the explanation is written in natural language, but it can only use the retrieved doc as context. If the AI call fails, it falls back to the template.

Planning took the longest

The building was not the slow part. Working out how the tool should be structured was. I decided what the report should look like first, since that seemed the easiest part to get right, and built the scanner and classifier behind it. It took about 20 commits before it worked, and more after that to refine it.

Testing it

First, a ground-truth check. I built a small sample repo with a labeled set of expected findings:

python -m tests.eval

It reports precision 1.00 and recall 1.00. That is only 5 expected findings, so I treat it as a sanity check, not proof.

The more useful test was giving it to other people. Three people ran it on real public repos in their own Codespaces: 6 scans across 5 repos.

Repo	Critical	High	Medium
permitio/supabase-fine-grained-authorization	0	0	4
John-Weeks-Dev/ebay-clone	0	0	1
supabase-community/nextjs-subscription-payments	1	4	4
salmandotweb/nextjs-supabase-boilerplate	1	1	1
KolbySisk/next-supabase-stripe-starter	2	1	3

One real finding, from nextjs-subscription-payments:

[HIGH] utils/supabase/admin.ts:17
process.env.SUPABASE_SERVICE_ROLE_KEY || ''

The explanation says this key gives full access that bypasses row level security and should only live in server-side environments, with a link to Supabase's migration guide.

What broke when other people used it

Three things failed, and none were bugs in the scanner:

No module named 'supabase_migrate.cost_tracker': a Codespace had cloned the repo before I pushed that file. Fix: push the file and run git pull.
run_and_log.sh: No such file or directory: a pasted setup block got cut off partway. Fix: paste it in one go and check with ls.
destination path already exists: a tester re-ran git clone into an existing folder. Fix: reuse the folder.

I would never have seen these alone. My instructions assumed a state that only existed on my machine.

Limits

Five repos is a small sample, and all of them are Next.js projects. It doesn't cover Flutter or plain Python backends. The testers followed a script I wrote instead of exploring freely. I see this as a first real-world pass, not a validation study.

What's next

Open a PR that renames the env var and adds a migration checklist
Optionally probe a live project to confirm which key format is configured
Replace the topic lookup with real embedding-based retrieval once the knowledge base grows

I created this for the H0: Hack the Zero Stack Hackathon. #H0Hackathon

Kavya — Sat, 27 Jun 2026 09:06:02 +0000

NourishIQ is a full-stack nutrition app built on Next.js, Amazon DynamoDB, and Vercel. Instead of forcing users to log height and age, it infers nutritional targets dynamically from meal patterns — less friction, higher retention.
Why DynamoDB
Every read in NourishIQ follows the same pattern: fetch one user's data by date range. Single-table design with composite keys handles this in one query, under 5ms, at any scale.
PK: USER#
SK: MEAL##
TTL on expiresAt auto-expires Travel Mode and Plate Scanner records. No cron jobs. Two GSIs handle cross-entity queries for scan history and regional travel data.
Why Vercel
Edge deployment kept DynamoDB latency low with zero infrastructure config. Environment variables wired in two minutes. Deploy on push.
Key features

Smart 19-day meal calendar (5 past, 14 future)
Plate Scanner — snap any meal, get macros + healthier swap
Green Speaker Pill — hands-free voice cooking instructions
Travel Mode — regional dietary guidance with auto-expiring data
Apothecary — preservative-free wellness remedies

Monetization: Free / $12 Pro / $20 Premium with family plans.
DynamoDB on-demand means zero cost at zero users, predictable cost at a million. That's the stack I'd use in production — so that's the stack I built on from day one.

H0Hackathon · AWS DynamoDB + Vercel

I opened a pull request on Netflix's codebase. It didn't get merged. Here's why that still mattered.

Kavya — Sat, 16 May 2026 07:29:17 +0000

Let me be honest with you. I was not sitting at a desk with a plan when this happened. I was looking for open source repositories to contribute to, mostly because I needed to build a portfolio and everyone online keeps saying "contribute to open source" without really telling you what that means when you are just starting out.
So I started applying.Metaflow caught my attention because it is a Python ML pipeline framework built by Netflix engineers and used in actual production machine learning workflows. Not a toy project. Not a tutorial repo. Something real people depend on.
I found issue #3144.

The bug
timeout_decorator.py had a problem. The file used signal.SIGALRM — a POSIX signal that lets you set an alarm for a process and interrupt it after a timeout. Clean concept. One problem: SIGALRM does not exist on Windows. It is a Unix-only feature.
So if you were a Windows user trying to use Metaflow's @timeout decorator, Python would throw an AttributeError or ImportError when it hit the signal.SIGALRM line. No helpful message. No graceful exit. Just a crash that tells you nothing useful about why it happened.
This is one of those bugs that is easy to miss when you are building on a Mac or Linux machine, which most ML engineers are. But for anyone on Windows trying to use the framework, it was a silent wall.

What I did
The fix itself was not complicated. I added import sys at the top of the file and wrapped the SIGALRM-dependent code in platform checks.
In task_pre_step, before any SIGALRM logic runs, I added:
pythonif sys.platform == "win32":
raise RuntimeError(
"The @timeout decorator is not supported on Windows "
"(SIGALRM is POSIX-only)."
)
In task_post_step, I added a guard so the cleanup code — signal.alarm(0) — would also be skipped on Windows:
pythonif sys.platform != "win32":
signal.alarm(0)
Eight lines changed. Five removed, eight added. The idea was simple: if you are on Windows, fail immediately with a clear message instead of crashing with a confusing error somewhere deeper in the stack.

The review
This is where it got interesting.
An automated reviewer called Greptile analyzed the PR and gave it a confidence score of 4 out of 5. Safe to merge. The logic was sound. The platform guard was correctly placed before any SIGALRM access could be reached, so the module-level import signal was harmless even on Windows.
But then it flagged something I had missed.

"The error raised here is RuntimeError, but the rest of this decorator uses MetaflowException for user-facing configuration errors."

It was right. I had used a generic Python exception. But everywhere else in that file — and across Metaflow's decorator system generally — they raise MetaflowException, which is the project's own exception class. It routes through Metaflow's formatting pipeline, gets caught cleanly by @catch, and produces a properly formatted error message for the user.
My RuntimeError bypassed all of that. It would work. But it was not how Metaflow does things. It was like writing a fix that solved the problem but ignored the style guide of the codebase you were writing it in.
That is a real thing you only learn by actually reading a large production codebase carefully. Not from tutorials. Not from LeetCode. From opening files and understanding how the pieces fit together.

Why it was closed
The PR was closed without merging. The maintainer closed it, which means either the fix needed changes, or there was something else going on with the issue. My best guess: they wanted MetaflowException instead of RuntimeError before merging, and I had not yet updated the PR when it was closed.
I am not going to pretend that does not sting a little. You spend time reading a codebase used in Netflix's production ML systems, you find a real bug, you write a fix that a bot rates 4 out of 5, and it still does not get merged.
But here is what actually happened. A bot trained on software engineering standards reviewed my code and gave it a near-passing score. A real maintainer looked at it. I learned what MetaflowException is, why it exists, and why consistency in exception handling matters at scale. I learned that production codebases have conventions that go beyond "does the code work" — they care about "does this code fit the system it lives in."
That is not a lesson you get from building your own projects. You only get it by reading someone else's.

What I would do differently
Change RuntimeError to MetaflowException. That is it. One word. And honestly I learned more from that one bot comment than from most courses I have taken, because it was specific, it was about real code I wrote, and it pointed to something I had to go understand before I could fix it. go understand before I could fix it.
If you are a student trying to break into engineering and you have been told to "just contribute to open source" without being told how — here is what actually helped me:
Find a bug that is small enough that you can understand the whole fix but real enough that it matters. Read the files around the bug, not just the bug itself. Understand the conventions of the codebase before you write a single line. And submit the PR even if you are not sure. The review will teach you more than the research.
The PR is closed. The branch is still sitting there with unmerged commits. And I now know exactly what SIGALRM is, why it does not exist on Windows, what MetaflowException is and why Netflix engineers created it, and how production-grade exception handling differs from "just throw an error and see what happens."
That is worth a lot more than a merged commit.

The PR is #3185 on Netflix/metaflow if you want to read the review yourself.

I built a Jira bot from my broken laptop because LinkedIn made me feel like I had to

Kavya — Tue, 07 Apr 2026 16:01:27 +0000

I was eating ramen and scrolling LinkedIn when I noticed a pattern. Project managers complaining that engineers never update Jira. Engineers complaining that PMs write tickets with zero context. Both sides agreeing that turning meeting notes into tickets by hand is miserable. Job posts asking for "Jira automation experience." Everyone nodding along, nobody actually building anything.

I'm a college student with zero work experience and a laptop that takes four minutes just to open Chrome. So obviously I decided to build the thing everyone was complaining about.

The real problem isn't Jira

Here's what nobody says out loud. The real problem is what happens after every meeting. Someone has to take everything people said and turn it into structured tickets. PMs don't want to do it, engineers don't want to do it, so it falls into a gap and either gets done badly or doesn't get done at all.

I figured if I could automate even 60% of that, I'd be solving something real. Not a tutorial project, an actual problem people with real salaries were venting about in public.

How it started, badly

I found the Jira API and Googled "Jira API free tier for students." I dug through forums and documentation for days because everything useful seemed to cost money, and I had no idea what I was doing.

My GitHub was rusty. My laptop runs on prayers and a battery that never charges past 40%. I wrote the first version in online compilers because my machine couldn't handle running a local server without freezing, until someone told me about Replit. That saved me. It took about two weeks to get something that actually ran.

What the first version did

You pasted a meeting transcript into a form. The app scanned it for action items using keyword matching, looking for things like "will," "to do," "action item," and "needs to." It then connected to the Jira API and created real tickets automatically. No OpenAI, no API bills, just Python, Flask, keyword logic, and a lot of Stack Overflow.

The part that actually humbled me

The API wasn't the hard part. The hard part was that people talk like humans.

"Maybe someone should look into that" is not an action item. "We should probably circle back on this" is not an action item. "I feel like the timeline needs revisiting" is definitely not an action item.

My first version created a Jira ticket for all three anyway. I spent days tweaking keyword rules to stop the bot from filing nonsense tasks. It's still not perfect, but it no longer creates a ticket every time someone says "we should." That gap between messy human language and structured systems is apparently what engineers at big companies deal with too. I didn't expect to stumble into it from a bowl of ramen.

Then I rebuilt it

The first version proved the idea could work and also made its limits obvious. Keyword matching was too brittle, and the app was annoying to run locally. More than that, I wanted the system to understand the context of a meeting instead of hunting for a few trigger words.

So I rebuilt it. The current version sends the transcript to a hosted OpenRouter model to extract structured action items instead of matching keywords. Once the model pulls out the action items, you review them and turn the ones you want into real GitHub Issues through the GitHub API.

The flow now: meeting transcript, AI extraction, human review, GitHub Issue. You still decide what actually becomes a ticket. I didn't want the model creating issues on its own for anything that sounded vaguely important.

Deployment was its own disaster

Vercel didn't work for me, I tried for a day, gave up, and moved to Render. Got it running, celebrated. Then my original Jira API key expired and I had to recreate every environment variable from scratch. One full extra day, for an expired key. Nobody warns you about that part. Credentials now live in environment variables instead of sitting in the frontend code.

What's still broken

It only handles plain text right now, no audio transcripts yet. It can't reliably assign tickets to specific people. The model can still misread ambiguous language, and the backend needs better timeout and failure handling for when an external API is slow.

One more thing worth being upfront about: the original version created Jira tickets, the current live version creates GitHub Issues. I'm keeping real Jira integration on the roadmap instead of pretending the current build already supports it.

Why I'm writing this

The LinkedIn posts that pushed me into building this were from people with years of experience who were still stuck on a problem a college student with a broken laptop could take a swing at. You don't need the job to build the thing. Build the thing, then go get the job.

Live demo: https://meeting-to-jira-assistant.vercel.app/

GitHub: https://github.com/k-kj0