DEV Community: Asuran

A charity does not close because its overhead was too high. I checked 328,186 tax returns.

Asuran — Sun, 06 Sep 2026 00:04:16 +0000

This is a submission for Weekend Challenge: Generosity Edition

I have given money to charities for years and I have never once known whether the one I gave to was about to close. The number everybody puts in front of you is overhead, the share of spending that does not go to programmes. Every rating site leads with it. I assumed it meant something.

So this weekend I downloaded the IRS Statistics of Income extracts of Form 990 and Form 990-EZ, which is 3,697,515 filings covering 700,873 organisations across fiscal 2017 to 2024, then asked a narrower question. Not whether a charity is efficient. Whether it is going to still be there.

I took the 328,186 organisations that filed a long-form Form 990 for fiscal 2018 or 2019, then checked which of them appear on any filing for fiscal 2022 or later. 8.88% do not. Then I scored two candidate signals inside each of ten spending deciles, so that nothing I found could turn out to be a story about big charities outliving small ones.

Feeding America spends $4.93 billion a year and holds 1.04 months of it in cash. The Greater Chicago Food Depository spends $261 million and holds half a month. Second Harvest Food Bank of Central Florida holds nine days. None of that is on any rating site, because the number nobody computes for you is the one that decides whether the lights stay on.

What I Built

Keepalive computes months of runway for 579,178 US nonprofits, straight off their own filings. Runway is cash plus savings divided by one month of spending. It is the number a finance director lives by and the number a donor never sees.

Across 1,573,687 long-form filings the median is 5.5 months. 33.5% hold under three months. 15.1% hold under one.

The site does four things with that.

Where does my gift buy the most time. Say what you can give, pick a cause and a state. It ranks real organisations by days of runway your money adds, which is 365 * yearly gift / annual spending. $25 a month is 12 hours of runway at a $260 million food bank and 9.4 days at a $23,000 one. The same money, three orders of magnitude apart in effect. That single line changed how I give.
Look up any of the 579,178 by name or EIN, with seven years of revenue, spending and cash on one chart.
Read the brief. Gemini writes it from a fixed packet of that filer's own figures and is handed nothing else, so there is nothing for it to invent. It has to return a line naming what a tax filing cannot tell you.
Check it. One click publishes the SHA-256 of the figures on screen and the brief just written as a memo on Solana devnet, so what Keepalive said about an organisation on a given date lives somewhere its author cannot quietly edit.

The finding

Both tables below hold inside every one of ten spending deciles.

Runway predicts survival. Thin runway is the worst of the three bands in all ten deciles. Pooled with deciles weighted equally: 86.79% of the under-three-months group was still filing, against 92.61% at three to twelve months and 93.56% above a year. The gap is 10.3 points in the smallest decile and 1.6 in the largest, so it bites hardest exactly where the money is smallest.

Fundraising thrift points the wrong way. The organisations that spent under five cents to raise a dollar survived less than the five-to-fifteen-cent band, in all ten deciles: 91.16% against 94.86%. Spending more on fundraising went with surviving more. In nine of the ten deciles the thriftiest band is the worst of the three outright. Only one of these two numbers is on the rating sites. It is the one that is backwards.

That is the starvation cycle, visible in tax returns. Judge a charity on how little it spends on itself and you reward the ones with no capacity to raise next year's money.

Demo

Live: https://keepalive.zkasuran.dev No sign-in, nothing to install.

Try it in 30 seconds:

Open the site. The two survival tables under The finding are the whole result, drawn from the same query.
In the search box type greater chicago food depository. Open it. The runway card reads 0.5 months on a $261m budget. The peer card shows 95.6% of organisations in its own spending decile and runway band still filing.
Scroll to The honest brief and wait about eight seconds. Gemini writes it live. Read the last line, the one that starts "What these filings cannot tell you".
Press Publish a checkable receipt. About four seconds later you get a Solana devnet signature. Open it. The memo on chain holds the SHA-256 of exactly what you just read.
Back at the top, set the amount to 25 per month, cause Food, agriculture and nutrition, state TN. The list re-ranks by days of runway your $300 a year adds.

Code

zkasuran / keepalive

Months of runway for 579,178 US nonprofits, read off their own IRS filings

Keepalive

A charity does not close because its overhead was too high. It closes because it ran out of months.

Keepalive reads 3,697,515 IRS filings and computes, for 579,178 US nonprofits, the one number no rating site puts in front of you: how many months of spending they hold in cash Then it tells you what your gift does to that number.

Live: https://keepalive.zkasuran.dev

Built for the DEV Weekend Challenge: Generosity Edition 4 to 7 September 2026. Everything in this repository was written inside that window.

The finding

Two candidate signals, measured on the same 328,186 organisations that filed a long-form Form 990 for fiscal 2018 or 2019, scored on whether the same EIN appears on any filing for fiscal 2022 or later. 8.88% do not.

Months of runway predicts survival. Under three months is the worst of the three bands in all ten spending deciles, with no exception.

…

View on GitHub

npm run data reproduces every number: it pulls the IRS extracts, loads 3.7 million filings, prints the finding and writes the static shards the site reads. It needs no credentials and no account.

How I Built It

There is no runtime database. The site is 4,542 static files on a CDN plus four small functions that hold keys a browser cannot have.

Search is a static inverted index. 579,178 names tokenise to 1,910,797 postings, hashed into 2,048 shard files. The browser hashes your query tokens, fetches only the shards it needs and intersects them. Typing "greater chicago food depository" costs three fetches and no server. Each posting list is ordered by spending, which matters more than it sounds: truncate a common token like "food" and the intersection silently stops finding real names. That was my first real bug.

Organisation records are sharded by EIN modulo 1024, so one lookup is one 250 KB fetch that the CDN then holds.

Google AI writes the brief under a JSON schema, from a packet containing every number it is permitted to mention and no others. Absent fields are dropped rather than sent as zero, because "not reported" and "$0" are different claims and a model handed a zero will tell you the charity has no employees. The system prompt forbids computing a new ratio. One measured detail: Gemini 3.5 Flash spends its thinking tokens out of the same maxOutputTokens budget, about 2,200 of them here, so a tight cap truncates the JSON and the parse fails. That looks exactly like a bad model and is not.

Solana is the only place the receipts live. Keepalive keeps no copy. Remove Solana and the app can no longer prove that today's number is the number it computed from the filing, which is the honest answer to "how do I know your AI did not make this up".

The transaction is built against the wire format rather than with a client library. A memo transaction is one signature, two account keys and one instruction. Ed25519 is already in crypto.subtle, so an SDK would have added megabytes to buy nothing. test/attest.wire.test.mjs proves those bytes equal the ones @solana/web3.js produces: message, signature and full serialized transaction, byte for byte, including a memo that crosses the compact-u16 boundary.

One thing I want to state plainly rather than hide. The signature is made on the server, where the key is. The transaction is submitted by your browser. That is not a design flourish. The public devnet RPC answers Cloudflare's egress with 403 Your IP or provider is blocked from this endpoint while a visitor's own connection is fine. That RPC allows any origin. So the key stays server side and the network call happens where the network works. The only thing a client controls is the blockhash, which is length checked and which cannot turn a memo into a transfer.

Snowflake is the warehouse path, in data/snowflake.sql: the same cohort plus one statement that cuts it into deciles then scores both signals inside every decile at once. Cortex does the language work next to the data, with AI_CLASSIFY over names the IRS only gave a letter code and AI_AGG writing one sentence per filer from all of its returns together. There is a licensing line I held to: Marketplace terms do not permit redistributing a dataset, so every per-organisation figure this site serves comes from my own public domain IRS download instead. Only aggregates ever leave a warehouse. Sources and the exact granting sentence for each are in DATA-SOURCES.md.

ElevenLabs reads it out, because the reason a lot of people cannot use a giving tool is that it is a wall of financial text. The free tier is about ten minutes of audio a month, so architecture had to do the work rather than budget: everything that never changes is pre-rendered once at build time by tools/narrate.mjs into static mp3. A visitor who plays the tour or the finding spends nothing. Only a brief about one specific filer is synthesised live, cached in the Worker by a SHA-256 of the text, so the second person to read the same organisation is free too. You can watch it happen: the response carries x-keepalive-audio: fresh the first time and cached after.

The tour is in English, Hindi, Tamil and Spanish. Gemini does the translation with an instruction to keep every figure exactly as stated. ElevenLabs speaks it. The English stays the source of truth. That is the one part of this build I would call generous rather than clever. A US tax filing is hard to read in your first language. The people most likely to be deciding about a small charity back home are not all reading English.

Two things that will bite anyone doing this on a free key. A scoped key answers 401 missing_permissions on GET /v2/voices, so a voice id has to be configured rather than discovered, with a short list of defaults to fall back through. Free accounts also get 402 paid_plan_required on library voices, so a voice id copied out of a blog post is a dead end. The four in the list are ones I verified synthesise on this key.

What is real and what is not

Every figure on an organisation page is that organisation's own reported number, labelled with the fiscal year, computed in your browser from a static file. Nothing is modelled and nothing is imputed.
Form 990-EZ does not break out cash, so EZ filers show no runway rather than a guess.
The survival tables are associations, not causation, controlled for size by decile and for nothing else.
Solana devnet, not mainnet. No money moves anywhere in this project. Keepalive is not a payment processor and never touches a donation.
Keepalive is not a charity rating. It can tell you what an organisation's finances look like. It cannot tell you whether they are good at the work. Neither can any rating site.
AI assistance (Claude) was used in building this. The design, the analysis and the verification are mine. Every number above came out of SQL I can rerun in front of you.

Prize Categories

Best Use of Google AI. Gemini writes every brief under a JSON schema from a packet of that filer's own figures, with a rule that a missing field means not reported. It also writes the narration translations without touching a single figure.
Best Use of Solana. A devnet memo is the only store of record for what this site published. Remove it and no claim on the page is checkable. The transaction is hand built and proved byte-identical to the reference implementation.
Best Use of ElevenLabs. The tour and the finding are pre-rendered at build time in four languages, so listening costs no credits and needs no key. A brief about one organisation is spoken live, then cached by a hash of the text.

The Snowflake path is written and in the repository as data/snowflake.sql, and the live deploy tells you plainly that its credential is not bound: /api/status returns snowflake: false. The finding tables you are reading were produced by the same SQL run locally in DuckDB rather than in a warehouse. I would rather say that than claim a category a judge cannot see working. If it changes before the deadline I will say so here in an edit, with the timestamp.

Thanks for a theme worth building for. The most useful thing I learned is that the kindest gift to a small charity is not the largest one, it is the predictable one. The number to ask about is months.

My checkout said it was ready for a month. Nobody could have paid.

Asuran — Fri, 04 Sep 2026 22:23:29 +0000

The dashboard for my payment provider reads, for the whole life of the account:

Revenue since inception   USD 0.00
Transaction History       Total count: 0
Users                     Total count: 0

Live mode and sandbox mode, same numbers. The easy reading is that nobody wanted it.

Here is the harder reading. Over the eight days my analytics still retains, 21 of 228 real visits reached the pricing page. Not one of those 21 had anything to click. The buy button was there. It was styled, it was enabled, it said "Sign in to start the trial". It had no click handler on it at all.

Three separate defects, none of them visible from reading the code, all three provable from the network tab.

One: my own content security policy blocked the SDK

The policy I shipped was tight on purpose. The whole frontend is first party, so I named exactly what it needed:

default-src 'self';
script-src 'self' 'unsafe-inline' https://esm.sh;
style-src  'self' 'unsafe-inline';
img-src    'self' data:;
connect-src 'self' https://esm.sh https://api.tiun.live https://api-sandbox.tiun.live;

Read that and it looks right. The SDK module comes from esm.sh, so esm.sh is a script source. The SDK talks to the API host, so the API host is a connect source. Done.

An SDK is not one request. Here is what init() actually does, from the shipped bundle:

let r = document.createElement("link");
r.rel = "stylesheet"; r.href = cssUrl;
document.head.appendChild(r);
let a = document.createElement("script");
a.src = scriptUrl; a.async = true;
document.head.appendChild(a);

It appends a stylesheet and a script pointing at the API host. Those are style-src and script-src decisions. The sign in surface renders in a frame, which is frame-src. With no frame-src the browser falls back to default-src 'self'. The one place I named the host was the one place it did not matter.

Driving the page over the DevTools protocol says it plainly:

requestWillBeSent   .../snippets/<id>/background_css
requestWillBeSent   .../snippets/<id>/background_js
Network.loadingFailed
Network.loadingFailed

Both fetch fine with curl. 84 KB of CSS, 506 KB of JS, 200 each. The refusal was mine.

The reason nobody noticed

waitForReady() resolves when the snippet posts back that it initialised. With the runtime bundle refused, that message never arrives, so the promise never settles. My code awaits it at module top level:

await tiun.waitForReady();
// everything below here never ran
for (const button of document.querySelectorAll("[data-buy]")) {
  button.addEventListener("click", () => tiun.checkout({ productId: product.id }));
}

The page did not throw. It did not show an error. It stopped, silently, above the line that wires the buttons. It kept the markup the HTML shipped with. That markup shows the sign in prompt and hides the buy controls, because that is the correct signed out state. A correct looking page with no behaviour behind it.

I had written a checkoutUnavailable() path for exactly this and it never fired, because nothing rejected.

Two: getUser is synchronous

Fixing the policy moved the failure one layer up. From the SDK source:

getUser() { return { isAuthenticated: this._isAuthenticated, user: this._user } }

No promise. My code:

const user = await tiun.getUser().catch(() => null);

.catch on a plain object is a TypeError. It is thrown inside an async function, so it does not crash the page, it becomes a rejected promise nobody is awaiting. That function is the one that decides what the top bar and the buy controls look like. It died on its first line, on every call, for a month. The only trace was a single Uncaught (in promise) line in a console nobody had open.

Three: the purchases are one level down

Same call, look at the shape again. It is { isAuthenticated, user }. The email and the entitlements live on the inner object. I read them off the outer one:

const access = Object.keys(user?.productAccess ?? {}).length > 0;

Always {}. Always false. So the control that hands a paying customer their CLI licence could never appear, for anyone, ever. If someone had pushed through the other two bugs and paid me money, they would have got nothing.

And a fourth, for free

for (const event of ["login", "logout", "checkout:complete", "user:updated"]) {
  tiun.on?.(event, paint);
}

The SDK emits seven event names. checkout:complete is not one of them. user:updated is not one of them. The real names are ready, login, logout, userChange, paywallShow, paywallHide and error. Subscribing to a name that is never emitted is not an error anywhere. It is a listener that waits forever. A completed purchase repainted nothing.

on() is called with ?. too, so even if the method vanished the line would stay quiet.

What I actually got wrong

Not the policy. Policies are fiddly and that mistake is cheap to make.

What I got wrong is that I treated waitForReady() resolving as proof the checkout worked. It is not proof of anything. It is one signal from one layer. Every layer under it can be broken while it still resolves. I built my whole readiness story on a check that could not fail.

I write a tool that finds exactly this in test suites. Tests that call a function and assert nothing. Assertions that cannot be false. Gates no workflow invokes. Every one of them is a signal that stays green because it is not actually connected to the thing it claims to measure. I had one of those in my own shop, on the page where people pay me.

The fix

The policy now names the hosts everywhere the SDK reaches through. Nowhere else:

script-src 'self' 'unsafe-inline' https://esm.sh <api hosts>;
style-src  'self' 'unsafe-inline' <api hosts>;
img-src    'self' data: <api hosts> https://assets.tiun.dev;
font-src   'self' data: <api hosts> https://assets.tiun.dev;
frame-src  <api hosts>;

The font host turned up on the next run, because the stylesheet asks it for one webfont. It gets font-src and img-src and nothing else. A font host has no business being a script source. Nothing is widened to a bare https:, which would allow every host on the internet and is the shortcut I did not want.

Then a readiness check that can fail:

function assertSdkArrived() {
  if (cspBlocked) throw new Error(CSP_BLOCKED);
  const loaded = performance.getEntriesByType("resource")
    .some((r) => r.name.includes("/background_js") && r.responseEnd > 0);
  if (!loaded) throw new Error("tiun runtime bundle never loaded");
  if (typeof tiun.login !== "function" || typeof tiun.checkout !== "function") {
    throw new Error("tiun sdk is missing login or checkout");
  }
}

A resource the policy blocked never enters the Resource Timing buffer, so asking the buffer is a real question with a real answer. Alongside it, a securitypolicyviolation listener records the directive:

const FATAL_DIRECTIVES = new Set(["script-src", "style-src", "frame-src", "connect-src"]);
document.addEventListener("securitypolicyviolation", (e) => {
  if (!String(e.blockedURI).includes("tiun")) return;
  if (FATAL_DIRECTIVES.has(e.effectiveDirective)) cspBlocked = `${e.effectiveDirective} blocked ${e.blockedURI}`;
});

That set matters. My first version treated any blocked provider URL as fatal, so the blocked webfont disabled a checkout that had just started working. A blocked font is ugly. A blocked script is a dead checkout. Only one of those should stop the sale.

Tests, since the whole point is not trusting a green light

19 of them. They pin facts rather than behaviour I cannot exercise headlessly.

One file reads the policy and asserts every directive the SDK needs names both hosts, that the font host is a font source but not a script or frame source, that nothing is a bare scheme, then that the directives with nothing to do with payments still read 'none'.

The other reads the frontend as text and holds it to the SDK: no .catch on getUser(), purchases read from the nested object by name, then every event subscribed to is one of the seven the SDK actually emits. It blanks comments before matching, because the comments describe the old wrong call and would otherwise match themselves.

128 tests pass now. They would all have passed before too, which is the point: none of them was looking here.

Where it stands

The sign in modal opens on margyn.xyz/pricing. Clicking that button did nothing yesterday.

I still have zero sales. That number has not moved. What changed is that it now means something about my product instead of something about my content security policy. Those are very different problems to have. For a month I was working on the wrong one.

The scanner is margyn, free for four checks, no account and no network call. Source is on GitHub.

A test said the server started. I deleted the server. It still passed.

Asuran — Fri, 28 Aug 2026 03:18:57 +0000

Here is a test from a real, well run Node project:

test('server starts', async (t) => {
  const app = build()
  await app.listen({ port: 0 })
  t.assert.ok(true, 'server started')
})

It reads fine in review. It runs green. Now delete the body of build() so the server never comes up. The test is still green, because the only thing it asserts is true. In the same file two more of these caught the error in a catch and asserted true there too, so even the failure path was green.

That is not a made up example. I found it in fastify at a pinned commit and opened a PR to fix it. More on that at the end.

A whole class of tests cannot fail

Once you start looking, the pattern turns up in a few shapes:

A literal: assert.ok(true), expect(1).toBe(1), a snapshot of a constant.
An assertion parked in a catch the happy path never reaches, so nothing is checked when the code works and nothing is checked when it breaks.
A status list that accepts both outcomes: assert.ok([200, 500].includes(res.status)).

Each one runs, counts toward coverage and guards nothing. Coverage is the trap. The line executed, so the tool that counts executed lines is happy. Whether the line would go red on a regression is a different question. It is the one that matters.

Why review misses it

A reviewer reading the diff sees a test called server starts, an await listen and a green tick. The name states intent. The assertion is what actually runs, yet ok(true) does not look like a problem until you stop and ask what would ever turn this test red. A missing check does not show up in a diff the way a wrong line does.

Finding them

I wrote a small scanner for this. No account, no config file, no network call:

npx margyn-scan /path/to/repo

One of its checks is cannot-fail: tests whose assertions hold whatever the code does. It also flags tests that assert nothing at all, files the build reads that git never committed, gates declared in package.json that no workflow invokes and linter exclusions that quietly drop tracked source. Every finding prints the command that reproduces it, so you confirm each one yourself instead of trusting a report.

The fastify case

The two tests above asserted ok(true) right after starting a server. I opened fastify/fastify#6962 to assert the server is actually listening instead. A maintainer reviewed it and suggested tightening it further to t.assert.ok(server.listening) with t.after for teardown. Both are in and the PR is open for review. The point is not that fastify is careless. It is one of the most carefully tested projects in the ecosystem, which is exactly why it matters that this still slips through.

The takeaway

A green suite tells you the tests ran. It does not tell you they would go red if the code they cover regressed. Those are two different claims. Teams merge on the first while believing the second. The gap is worth auditing, by hand or with something like margyn.

I built a scanner that audits your test suite instead of your code

Asuran — Tue, 18 Aug 2026 01:14:39 +0000

A passing test suite is supposed to mean something. Here are three ways it lies. All three stay green forever.

A test that asserts nothing. It calls the function, nothing throws, the runner prints a tick. It counts toward coverage and guards nothing. fastify at commit 6e95cb9 has seven of them.

An assertion that cannot fail. A literal answered inside a catch, a swallowed assertion, a status list that accepts both the success and the failure. The test reads as rigorous and holds whatever the code does. fastify has two.

A gate nobody invokes. A test-cov or verify script sits in package.json, reads as coverage to every reviewer, then no workflow ever calls it. express declares three.

None of that is visible to a code reviewer, to a coverage percentage or to an AI reading the diff, because the absence of a check does not appear in a diff.

So the tool reads the checks rather than the code

npx margyn-scan /path/to/repo

No account, no config file, zero dependencies, nothing uploaded. It answers in about a second. Every finding prints one command that reproduces it on your machine.

Six checks: no-assertion, cannot-fail, ignored-source (a file the build reads that git never committed, so a clean clone cannot build), unrun-check, lint-blindspot (linter exclusions that come from the ignore file rather than the linter's own config) and a mutation proof.

Measured at pinned commits, nothing tuned for the demo and nothing left out because the number was inconvenient:

Repository	Commit	Findings
chalk/chalk	`661317e`	0
sindresorhus/execa	`8017b27`	0
sindresorhus/got	`e3924aa`	1 unrun gate
expressjs/express	`a371447`	3 unrun gates
fastify/fastify	`6e95cb9`	13 (7 assert nothing, 2 cannot fail, 4 unrun)

Proof mode, because a scanner should not be believed either

npx margyn-scan . --prove

It runs each finding's own command, reads the output for the markers that finding predicted, then certifies it REPRODUCED. Anything it cannot reproduce is RETRACTED and dropped, so a CI gate never fails a build on a claim the tool could not show on your own tree. On fastify today: 13 findings, 13 reproduced.

That mode exists because the tool was badly wrong once. An earlier version of ignored-source produced 22 false positives across four real repositories. Proof mode certified every one of them, because the check and its proof had inherited the same wrong premise. I wrote that up separately, fixture included, since it is the more interesting half of building this.

It runs in CI and posts on the pull request

- uses: zkasuran/margyn@v0
  with:
    path: .
    comment: true
    sarif: true

It comments on the request, edits that same comment in place on every push, writes the report to the job summary and uploads the findings to code scanning, all with your own GITHUB_TOKEN and no service of mine in the path.

There is a live run to click rather than a screenshot to trust: pull request 1 plants two faults on purpose, a test that calls the scanner and asserts nothing plus a script no workflow invokes. The suite still reads 109 tests passing. The comment lists both findings with a reproduction each, both appear in the Security tab, then the job exits 1, which is the gate working.

What it does to itself

The mutation proof inverts a line, runs your suite, then reports the suite that stayed green anyway. Over this repository: 40 files tracked as source, 27 carry a mutation it knows how to make, 27 mutated, 27 caught, no survivors, across 108 tests.

Two honest numbers to go with that. It takes 208 seconds, because every mutation runs the whole suite once, which is why the default cap is four rather than every file. And zero survivors is a claim about this suite against seven operators, not a claim that the code is correct.

The first time it ran on itself it found eight survivors, one of them inside the mutation checker. The one that mattered most was in the worker: inverted, the entitlement branch handed a licence to every customer who had not paid. Nothing was watching that line.

What it will not do

It does not test your product, it audits the suite you already have. It does not upload your code, because there is no endpoint that accepts it. It will not tell you your code is correct. It tells you which of your existing checks cannot fail, which is a smaller claim and a checkable one.

The five static checks are free forever. The mutation proof is the paid one, because it runs your suite N times and that is the part with a real cost.

Try it on something you own

npx margyn-scan .

MIT, no telemetry, no account: margyn.xyz and github.com/zkasuran/margyn

The question I would genuinely like answered, because the default is still open: when a tool finds a hollow test in your suite, should it fail the build or only comment on the pull request? Margyn defaults to failing. I am not certain that is right.

Built during the tiun x Microlaunch challenge on hackwithus.dev.

AI assistance (Claude, Anthropic) was used while building this and while writing this post. The design, the review and every number above are mine. Each number ships with the command that re-derives it.

My scanner was wrong 22 times and its own proof certified every one

Asuran — Tue, 18 Aug 2026 00:53:06 +0000

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

I built a scanner that audits the verification layer of a repository rather than the code. One of its checks looks for a file the build reads that git never committed: the file is on your disk untracked, so every local run is green while a clean clone or a CI runner cannot read it at all. The diff looks innocent because the defect is an absence.

Because a scanner that only asserts is not much better than the tests it audits, it also has a proof mode. Every finding carries a machine-checkable command. --prove runs that command, reads the output for the markers the finding predicted, then certifies the finding as REPRODUCED. Anything it cannot reproduce is retracted and dropped, so a CI gate never fails a build on a claim the tool could not show on your own tree.

Then I pointed it at five real repositories I had lying around. It produced 22 findings on four of them. Every single one was wrong. Here is the part that still bothers me: the proof certified all 22.

What the false positive looked like

Reduced to the shape it kept taking, on a repository anybody can build in ten seconds:

mkdir -p web/public/tour web/src && git init
echo webm-bytes > web/public/tour/clip.webm
echo 'export const clip = "/tour/clip.webm";' > web/src/app.js
printf 'node_modules\nweb/dist\n' > .gitignore
git add -A && git commit -m "app plus the clip it plays, dist ignored"
npm run build     # or just: mkdir -p web/dist/tour && cp web/public/tour/clip.webm web/dist/tour/

clip.webm is committed. It sits in web/public, which is exactly where a Vite or Next project keeps assets it wants copied verbatim. The build then writes a second copy into web/dist, which is gitignored because a clean clone rebuilds it.

My check walked the source, found "/tour/clip.webm", resolved it against the files on disk, hit web/dist/tour/clip.webm first, saw that git ignores it and reported HIGH: the build reads a file that is not in the commit.

1. web/dist/tour/clip.webm is read by web/src/app.js but git ignores it, so it is not in the commit
   HIGH  ignored-source  web/dist/tour/clip.webm
   ignore rule: .gitignore:2:web/dist
   why: A clean clone or a CI runner cannot read this file.

Read on its own, that finding is defensible. The file it names really is untracked. Every fact in it is true. It is still wrong, because the thing the reader asked for is in the commit. A clean clone answers the request perfectly.

On the real repositories it was the same fault at scale: a Vite app reporting its whole public directory, a Foundry project reporting contracts/out (declared out = "out" in its own foundry.toml), a CLI reporting dist/cli.mjs (declared outdir: "dist" in its own build script). 22 findings, 4 repositories, zero real defects.

The part that actually scared me

Here is the same fixture through proof mode, on the unfixed scanner:

1. web/dist/tour/clip.webm is read by web/src/app.js but git ignores it, so it is not in the commit
   HIGH  ignored-source  web/dist/tour/clip.webm  REPRODUCED
   MARGYN_ABSENT_FROM_HEAD
   MARGYN_PRESENT_ON_DISK

2 findings: 2 reproduced.

REPRODUCED. The proof ran, both markers matched and the tool certified its own mistake with a green badge.

The proof was this:

git archive HEAD | tar -t | grep -qx 'web/dist/tour/clip.webm' || echo 'ABSENT from HEAD: web/dist/tour/clip.webm'
test -f 'web/dist/tour/clip.webm' && echo 'PRESENT on disk: web/dist/tour/clip.webm'

Both lines are correct. web/dist/tour/clip.webm genuinely is absent from HEAD and genuinely is present on disk. The proof passes because it asks the same wrong question the check asked: is this path committed, when the question that decides the bug is does anything in the commit answer the path the reader asked for.

That is the lesson I paid for. A check and its proof can agree, both be internally valid and both be wrong, because they inherited the same premise. Independent verification means asking a different question, not running the assertion twice.

The two fixes

A reader asks for a path, not for a file on your disk. The check now collects every needle a reader names, then reports only when no committed file answers it. web/public/tour/clip.webm in the commit satisfies /tour/clip.webm, whatever the build left in dist. The proof asks that question too, so a finding that slips through retracts itself instead of failing somebody's build over a copy of a committed file.

Regenerated output is not missing source. The check skips output a tool in the repository declares it writes: Foundry's out from foundry.toml, a Vite or Next or Cargo target from the script that runs it, an outdir in a build script or a tsconfig. Read from declarations and resolved to real paths, never from the directory happening to be called dist.

That second rule matters more than it looks. One of the five repositories had vendored real source into vendor/dist, a path no tool there declares. That is exactly the defect this check exists for. A crude "ignore anything named dist" would have deleted the only true positive in the set.

So the fixture keeps both cases. Same tree, one import added, scanner at HEAD:

1. vendor/dist/real.mjs is read by web/src/vendorised.js but git ignores it, so it is not in the commit
   HIGH  ignored-source  vendor/dist/real.mjs
   reproduce:
     git archive HEAD | tar -t | grep -qE '(^|/)dist/real\.mjs$' || echo 'NOTHING in HEAD answers dist/real.mjs'

The build copy is gone. The vendored module is still reported. And look at the new reproduce line: it asks whether anything in HEAD answers the reference, which is the question the fix is built on.

Verification

4 regression tests in test/checks.test.mjs, one per direction: quiet when the commit answers the path, still loud when nothing does, quiet on declared build output, still loud on vendored source under a path that only looks built.
The fixture above, run against the pre-fix commit and against HEAD: 2 findings before, 1 after, then the one that survives is the real one.
Full suite 108 tests passing. The tool's own mutation proof mutates all 27 mutable files of 40 tracked and reports no survivors.

While I was in there, one more thing turned up that nothing was watching: the SARIF helpUri for the mutation rule pointed at /docs#mutation while the docs heading carried id="mutation-check", so every uploaded finding linked to nothing. There is a test now that resolves the helpUri of every check the scanner can emit.

What I would tell my past self

Write the check and the proof from different premises. Otherwise the proof is a spell-check on the check's own reasoning. Mine was, for 22 findings, with a green badge on each.

Code: the fix is one commit, efc5657, in github.com/zkasuran/margyn. The scanner runs with no account and no config: npx margyn-scan /path/to/repo. --prove is the mode that got humbled here.

AI assistance (Claude, Anthropic) was used while writing this post and while implementing the fix. The bug, the reduced fixture, the two rules and every number above were verified by me by running them: the outputs quoted are captured stdout from the pre-fix commit and from HEAD, not retyped.

Pup Card: what's your dog really thinking? (Gemini 3.5 Flash)

Asuran — Fri, 14 Aug 2026 14:10:06 +0000

This is a submission for Weekend Challenge: Dog Days Edition.

What I Built

Pup Card turns one dog photo into a shareable card. Drop in a photo or hit Surprise me for a random dog. Gemini 3.5 Flash reads the picture and hands back:

the likely breed with a confidence score, plus the mix if it is not purebred
the dog's mood and a plain read of its body language
a first-person caption, as if the dog is talking
two or three breed-appropriate care tips
a fun fact

It all renders as a card you can download as a PNG and share. I wanted something that was genuinely fun to use on a Saturday and that leaned on the one thing a multimodal model is really good at: looking at an image and saying something specific and true about it.

Demo

Live demo: https://pupcard.vercel.app

It needs no login and runs on your phone. If you do not have a dog photo on hand, the Surprise me button pulls a random one so you can try it right now.

Code

zkasuran / pupcard

Snap a dog photo, get an AI Pup Card: breed, mood and what they're thinking. Powered by Gemini 3.5 Flash.

🐶 Pup Card

Snap a dog photo and get back a Pup Card: the likely breed, a read on the dog's mood and body language, a first-person line of what they are probably thinking and a few care notes. One multimodal call to Google Gemini 3.5 Flash does the whole read.

Built for the DEV Weekend Challenge: Dog Days, for the Best use of Google AI category.

Live demo: https://pupcard.vercel.app

What it does

Upload a dog photo (or hit Surprise me to pull a random dog from dog.ceo).
Gemini 3.5 Flash looks at the image and returns a structured read: breed guess with a confidence score, likely mix, mood, body language, a playful first-person caption, 2-3 care tips and a fun fact.
The result renders as a card you can download as a PNG and share.

No dog photo on hand? The Surprise me button means anyone can…

View on GitHub

How I Built It

The whole read is a single generateContent call to gemini-3.5-flash. The photo goes in as inline image data next to a prompt that asks for JSON in a fixed shape. A zod schema validates the response so the front end always gets the same fields. If the model returns malformed JSON the server retries once with the parse error fed back. If the primary model is overloaded or out of quota it falls back to gemini-2.5-flash.

The stack is deliberately small:

Gemini 3.5 Flash through @google/genai for the read
TypeScript everywhere, with Hono for the local server
plain Node serverless functions on Vercel for /api/analyze and /api/random-dog, so there is no long-lived server to run
a vanilla HTML, CSS and JS front end with a <canvas> export for the downloadable card, so there is no build step and nothing shipped to the browser but three static files
the free dog.ceo API for the random dog

Two details I liked. Photos are downscaled in the browser before upload, which keeps the request tiny and the read fast. And the caption is where 3.5 Flash shows off: it picks up on the actual photo, the odd-colored eyes, the golden-hour light, the paw draped over a toy, instead of writing something generic.

The Gemini key stays on the server. The public endpoint has no login, so it is guarded by a size cap and a simple per-IP rate limit instead.

Prize Categories

Best Use of Google AI.

Gemini is not a feature bolted onto Pup Card, it is the product. One multimodal Gemini 3.5 Flash call does the breed identification, the mood and body-language read, the writing and the care tips, all returned as structured JSON that the card renders directly. There is no separate model, no rules engine and no template behind it.

Built over the challenge weekend. I used an AI coding assistant to help write it, then designed the prompt, reviewed the code and tested the whole thing end to end against real dog photos with live Gemini calls before shipping.

The reasoning tokens Sentry's Vercel AI traces dropped for Gemini

Asuran — Fri, 14 Aug 2026 10:06:17 +0000

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

The bug

Sentry's JavaScript SDK auto-instruments the Vercel AI SDK, so every generateText or streamText call shows up as a gen_ai span with token usage attached. When the model is a Gemini reasoning model, that usage was wrong: the span undercounted the output and the total because it silently dropped Gemini's reasoning tokens.

Gemini reports its reasoning ("thoughts") tokens separately from the visible answer. The AI SDK's outputTokens covers only the candidate answer and exposes the reasoning count through providerMetadata.google.usageMetadata.thoughtsTokenCount. Sentry's getProviderMetadataAttributes() handled OpenAI, Anthropic, Bedrock and DeepSeek metadata, but it never looked at the Google or Vertex block, so the reasoning tokens vanished from the span and the total was computed as input plus candidate-only output.

On a real Gemini call this is not a rounding error. The model returned usageMetadata { promptTokenCount: 14, candidatesTokenCount: 1, thoughtsTokenCount: 100, totalTokenCount: 115 }. Sentry recorded output_tokens: 1 and total_tokens: 15, hiding 100 reasoning tokens. For a reasoning model the reasoning tokens are most of the cost, so the trace understated real usage by nearly 8x.

Bug Fix or Performance Improvement

The fix adds a Google and Vertex branch to getProviderMetadataAttributes() in packages/server-utils/src/ai/vercel-ai/index.ts. It reads providerMetadata.{google|vertex}.usageMetadata and, when thoughtsTokenCount is greater than zero, sets the output to candidatesTokenCount + thoughtsTokenCount, sets the total from the real totalTokenCount and records the reasoning breakdown under gen_ai.usage.reasoning.output_tokens.

Deriving the output from the raw candidate and thoughts counts, rather than adding reasoning onto the SDK's existing value, is deliberate: it stays correct even if a future AI SDK version folds reasoning into outputTokens itself, so it cannot double count. The branch is gated on thoughtsTokenCount > 0, so a non-reasoning Gemini response is left exactly as it was. Both the OpenTelemetry span path and the ai tracing-channel path go through this one helper, so both emit the corrected shape.

My Improvements

I added a test file with four cases. A Gemini reasoning response now records output_tokens: 101, total_tokens: 115 and gen_ai.usage.reasoning.output_tokens: 100. The vertex metadata variant is handled the same way. A non-reasoning response is unchanged. Run against the current source the three reasoning cases fail (expected 1 to be 101) and the non-reasoning case passes, which pins the bug. With the fix all four pass.

Green on the repo's own gates: the full @sentry/server-utils vitest suite (377 passing across 40 files, my four added), oxlint --type-aware, oxfmt --check and tsc on the source types all clean. I confirmed the fix against the AI SDK's own source: convert-google-usage.ts maps output to candidates plus thoughts and reasoning to thoughts, which is exactly the accounting the fix uses.

Best Use of Sentry

This is a fix to Sentry's own JavaScript SDK, in the Vercel AI instrumentation that feeds the AI monitoring product. Token usage on a gen_ai span is what teams read to track model cost and behavior. For a reasoning model the reasoning tokens are the bulk of the spend, so an output_tokens that omits them makes the trace understate cost in the direction that hurts most. After the fix the span carries the real output and total, so Sentry's usage numbers match what Gemini actually counted.

Best Use of Google AI

I verified this end to end with a real Google Gemini reasoning call, because the whole bug only appears when a model emits thoughtsTokenCount. A real gemini-3.6-flash request returned { promptTokenCount: 14, candidatesTokenCount: 1, thoughtsTokenCount: 100, totalTokenCount: 115 }. Fed through the actual Sentry Vercel AI processor, the emitted span attributes were output_tokens: 1, total_tokens: 15 before the fix and output_tokens: 101, total_tokens: 115, reasoning.output_tokens: 100 after. Google Gemini produced the reasoning tokens. Sentry is where they reappear once the SDK reads the Google usage metadata correctly.

PR: getsentry/sentry-javascript#23433, from branch fix/vercel-ai-gemini-reasoning-tokens. Found by probing the integration with real Gemini traffic, not from a filed issue.

AI disclosure

AI assistance (Claude, Anthropic) was used in developing this change. The design, review and verification were done by the author. Verified locally before submitting: the four new tests fail on the unpatched source and pass with the fix, the @sentry/server-utils suite (377 passing), oxlint --type-aware, oxfmt --check and tsc on the source types, plus a real Gemini reasoning run showing the span output and total tokens corrected.

One tool call, counted twice: a Google GenAI streaming double-dip in Sentry's JS SDK

Asuran — Fri, 14 Aug 2026 09:44:00 +0000

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

The bug

When you call @google/genai in streaming mode and the model asks to run a tool, Sentry's JavaScript SDK records that tool call to the span twice. One tool call in, two entries out.

The attribute that carries them is gen_ai.response.tool_calls. It should hold one object per call. For a single streamed controlLight call it held two. Worse, the two did not even agree on their shape. Here is a real capture, which I come back to at the end:

[
  {"id":"call_2079699","args":{"colorTemperature":"warm","brightness":30},"name":"controlLight"},
  {"type":"function","id":"call_2079699","name":"controlLight","arguments":{"colorTemperature":"warm","brightness":30}}
]

Same id, same call, listed twice. One entry keys the parameters under args, the other under arguments. Anything reading this later sees two tool invocations where the model made one.

Following the value

The streaming instrumentation lives in packages/server-utils/src/ai/google-genai/streaming.ts. Every chunk of the stream runs through handleCandidateContent. That function wrote tool calls from two places:

function handleCandidateContent(chunk, state, recordOutputs) {
  if (Array.isArray(chunk.functionCalls)) {
    state.toolCalls.push(...chunk.functionCalls);          // push #1
  }

  for (const candidate of chunk.candidates ?? []) {
    // ...finish reasons...
    for (const part of candidate?.content?.parts ?? []) {
      if (recordOutputs && part.text) state.responseTexts.push(part.text);
      if (part.functionCall) {
        state.toolCalls.push({                              // push #2
          type: 'function',
          id: part.functionCall.id,
          name: part.functionCall.name,
          arguments: part.functionCall.args,
        });
      }
    }
  }
}

Push #1 spreads chunk.functionCalls into the accumulator. Push #2 walks candidate.content.parts and pushes every functionCall it finds. They look like two different sources. They are not.

chunk.functionCalls is a getter on the @google/genai response object. Here is what it actually does inside the SDK:

get functionCalls() {
  // ...
  const functionCalls = this.candidates?.[0]?.content?.parts
    ?.filter(part => part.functionCall)
    .map(part => part.functionCall)
    .filter(fc => fc !== undefined);
  // ...
  return functionCalls;
}

It reads the exact same candidates[].content.parts that push #2 iterates, filters for functionCall and hands them back. So both pushes are pulling the identical tool call out of the identical parts array. The first keeps the SDK-native shape { id, name, args }. The second rebuilds it as { type, id, name, arguments }. Two views of one thing, both written down.

The non-streaming path never had this problem. Its addResponseAttributes reads tool calls once, straight from response.functionCalls, then emits a single entry per call. So streaming and non-streaming disagreed on both the count and the key name for the very same response.

The fix

There is a single source of truth here: the SDK accessor the non-streaming path already trusts. Take the tool calls only from chunk.functionCalls and drop the second push:

function handleCandidateContent(chunk, state, recordOutputs) {
  // `chunk.functionCalls` is the SDK accessor over the candidate's function-call parts,
  // so it is the single source of truth for tool calls. Also reading `part.functionCall`
  // from those same parts would record every call twice, with two different shapes. This
  // mirrors the non-streaming path, which likewise takes tool calls from `response.functionCalls`.
  if (Array.isArray(chunk.functionCalls)) {
    state.toolCalls.push(...chunk.functionCalls);
  }

  for (const candidate of chunk.candidates ?? []) {
    // ...finish reasons...
    for (const part of candidate?.content?.parts ?? []) {
      if (recordOutputs && part.text) state.responseTexts.push(part.text);
    }
  }
}

I kept chunk.functionCalls rather than the parts loop on purpose. Both code paths now share one source and emit the SDK-native shape, so streaming output matches non-streaming output byte for byte. That is also how the OpenAI and Anthropic integrations in this repo are built: their streaming paths reconstruct the exact tool-call shape their non-streaming paths produce. The deprecated gen_ai.response.tool_calls example happens to show { name, arguments }, but no provider integration normalizes to that literally (Anthropic keeps input, OpenAI nests under function), so consistency within a provider was the property worth protecting.

Proving it on real traffic

I did not want to trust a mock for this. I made one real streaming call to gemini-3.6-flash with a controlLight tool, captured the actual chunks the model sent back (response id IuF-auTiDpW2g8UPnNDKsAI), then replayed that identical response through the instrumentation twice: once against develop, once with the fix.

Before, gen_ai.response.tool_calls:

[{"id":"call_2079699","args":{"colorTemperature":"warm","brightness":30},"name":"controlLight"},{"type":"function","id":"call_2079699","name":"controlLight","arguments":{"colorTemperature":"warm","brightness":30}}]

After:

[{"id":"call_2079699","args":{"colorTemperature":"warm","brightness":30},"name":"controlLight"}]

One real call, one entry.

A unit test covers the single-call case, several calls arriving across chunks and the recordOutputs: false case, then checks that the non-streaming path still records one entry in the same shape. It fails on develop with two entries and passes with the fix. Locally the full @sentry/server-utils unit suite is green (377 passing), with oxlint, oxfmt --check and the TypeScript build all clean.

The change is open as getsentry/sentry-javascript#23432.

AI assistance (Claude, Anthropic) was used in developing this change. The design, review and verification were done by me. I verified it locally before submitting: the new and existing @sentry/server-utils unit tests, oxlint, oxfmt --check and the TypeScript build all pass, plus the real gemini-3.6-flash run captured before and after.

The hidden svg Biome flagged anyway: a noSvgWithoutTitle false positive

Asuran — Fri, 14 Aug 2026 08:13:58 +0000

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

The bug

A Biome user filed issue #11317: the noSvgWithoutTitle lint rule flagged <svg aria-hidden><rect /></svg>, even though that svg is hidden from the accessibility tree and does not need a title. Write it as <svg aria-hidden="true"> or <svg aria-hidden={true}> and the rule stays quiet. Write it with the JSX boolean shorthand <svg aria-hidden> and the rule reports "title element cannot be empty". Same meaning, different result.

The shorthand is not a niche style. In JSX, aria-hidden with no value is exactly aria-hidden={true}, the same way disabled is disabled={true} on an input. React users write it constantly, so the rule was punishing correct, accessible code.

Following the value

The rule lives in crates/biome_js_analyze/src/lint/a11y/no_svg_without_title.rs. The guard that is supposed to let a hidden svg through looked like this:

if let Some(aria_hidden_attr) = node.find_attribute_by_name("aria-hidden")
    && let Some(attr_static_val) = aria_hidden_attr.as_static_value()
{
    let attr_text = attr_static_val.text();
    if attr_text == "true" {
        return None;
    }
}

Read it top down. Find the aria-hidden attribute. Read its static value. If that value is the string "true", return None, which means no diagnostic. Reasonable for aria-hidden="true" and aria-hidden={true}. The trouble is the second line, as_static_value().

Here is what that helper does, in crates/biome_js_syntax/src/jsx_ext.rs:

pub fn as_static_value(&self) -> Option<StaticValue> {
    self.initializer()?.value().ok()?.as_static_value()
}

The first thing it touches is self.initializer()?. An initializer is the = something part of an attribute. aria-hidden="true" has one. aria-hidden={true} has one. The bare shorthand aria-hidden has none. For the shorthand, initializer() returns None, the ? short circuits and as_static_value() returns None. The && let Some(..) in the guard fails, the whole block is skipped and the svg falls through to the title checks and gets flagged.

So the rule never actually decided the shorthand was not hidden. It just never got far enough to ask. The value was gone one line before the comparison that mattered.

The fix

The shorthand carries its truth in its presence, not in a value. The moment we know the attribute exists but has no initializer, we can treat it as true and stop:

if let Some(aria_hidden_attr) = node.find_attribute_by_name("aria-hidden") {
    // In JSX the boolean shorthand `aria-hidden` (an attribute with no
    // initializer) is equivalent to `aria-hidden={true}`, so it hides
    // the svg from the accessibility tree and no title is required.
    aria_hidden_attr.initializer()?;
    if let Some(attr_static_val) = aria_hidden_attr.as_static_value()
        && attr_static_val.text() == "true"
    {
        return None;
    }
}

aria_hidden_attr.initializer()? is the whole fix. If there is no initializer we are looking at the shorthand, so ? returns None from the rule and no diagnostic is raised. If there is an initializer, the existing "true" check runs exactly as before, so aria-hidden="true", aria-hidden={true} and aria-hidden={false} all keep the behavior they had. Clippy insists on the ? form here over an explicit if ... .is_none() { return None; }. Biome's CI denies warnings, so the terse version is the one that compiles clean.

Watch it fail, then pass

I added two valid cases to the rule's spec at crates/biome_js_analyze/tests/specs/a11y/noSvgWithoutTitle/valid.jsx:

<svg aria-hidden><rect /></svg>
<svg aria-hidden={true}><rect /></svg>

With the source reverted to the old guard but these cases in place, the spec test fails on exactly the shorthand:

× Alternative text title element cannot be empty
  > 43 │  <svg aria-hidden><rect /></svg>

Line 44, <svg aria-hidden={true}>, does not fail, which matches the report: the value forms always worked, only the shorthand was broken. Put the one-line fix back and both cases pass while the invalid.jsx spec still flags every svg that genuinely has no title.

The rest of the gates are green too. cargo run -p rules_check passes, so the new valid example I added to the rule's documentation is checked the same way. cargo fmt --all --check is clean. cargo clippy -p biome_js_analyze --all-features --all-targets -- --deny warnings is clean. The snapshot regenerates with INSTA_UPDATE=always and produces no changes beyond the new input lines.

The change

This is a fix inside Biome itself, in the linter. Issue #11317, pull request biomejs/biome#11334, branch fix/no-svg-without-title-shorthand-aria-hidden at commit 5d92567. One statement of source in no_svg_without_title.rs, two spec cases, a documentation example and a changeset. A dead read of a value that was never there, fixed by asking the question one line earlier.

AI disclosure

AI assistance (Claude, Anthropic) was used to trace the root cause, write the fix and the test cases, then run the checks. I own the change, reviewed it and verified it locally before submitting. Verified: the rule spec test passes with the fix and fails on the shorthand case without it; cargo run -p rules_check, cargo fmt --all --check and cargo clippy -p biome_js_analyze --all-features --all-targets -- --deny warnings are clean; the snapshot regenerates with no changes.

The fallback that never fired: empty SDK name and version in Sentry .NET console apps

Asuran — Thu, 13 Aug 2026 01:33:31 +0000

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

The bug that only showed up in console apps

A Sentry .NET user filed issue #5352: running the Sentry.Samples.Console.Basic sample, every structured log went out with an empty sentry.sdk.name and an empty sentry.sdk.version. They also suspected trace metrics had the same problem. They were right.

Those two attributes are not decoration. They tell Sentry which SDK produced a log or a metric. Lose them and a whole class of apps ships telemetry that cannot be attributed back to the .NET SDK. The strange part: the exact same logging code inside an ASP.NET Core app was fine. Only console apps dropped the fields. That split is the whole story, so this post walks the trace that explains it.

Following the value

Logs and metrics both end up in one method, SetDefaultAttributes in src/Sentry/Protocol/SentryAttributes.cs. Before the fix it read the SDK fields straight off the object it was handed:

if (sdk.Name is { } name)       { SetAttribute("sentry.sdk.name", name); }
if (sdk.Version is { } version) { SetAttribute("sentry.sdk.version", version); }

Nothing wrong on its face. If Name and Version are set they get written. If they are null the attributes are quietly skipped. So the real question is what sdk is on the console path.

Two call sites feed this method:

// src/Sentry/SentryLog.cs:153
sdk ??= scope?.Sdk ?? SdkVersion.Instance;

// src/Sentry/SentryMetric.Factory.cs:23
metric.Attributes.SetDefaultAttributes(options, scope?.Sdk ?? SdkVersion.Instance);

Both look defensive. Both say "use the scope's Sdk, otherwise fall back to SdkVersion.Instance". SdkVersion.Instance is the populated object, with Name = "sentry.dotnet" and the assembly version. So why does the fallback never help?

Here is the line that decides it, in src/Sentry/Scope.cs:277:

public SdkVersion Sdk { get; } = new();   // Name = null, Version = null

Scope.Sdk is auto-initialized to new SdkVersion(). That object exists, its Name and Version are just null. Because the property is never null, scope?.Sdk ?? SdkVersion.Instance always resolves to scope.Sdk and never reaches SdkVersion.Instance. The ?? only fires when scope itself is null. The fallback everyone wrote was dead code.

That empty object flows into SetDefaultAttributes, both guards see null, so both attributes drop out.

Why ASP.NET Core escaped

The framework integrations fill the scope's Sdk. ASP.NET Core does it in its middleware (src/Sentry.AspNetCore/SentryMiddleware.cs:257-258), setting scope.Sdk.Name and scope.Sdk.Version. Once those are non-null the guards pass and the attributes appear. The core Enricher populates the Sdk on events and transactions, never on the scope and never on the logs or metrics path. So a plain console app, with no integration touching scope.Sdk, leaves it empty. That is the difference between the two app types, all the way down.

The fix

One change, at the single point both logs and metrics share. Fall back per field to the populated instance when the incoming field is null:

// Fall back to the populated SDK instance when the scope's Sdk was not filled in by a framework
// integration, e.g. in console apps, so logs and metrics still carry the SDK name and version (see #5352).
if ((sdk.Name ?? SdkVersion.Instance.Name) is { } name)
{
    SetAttribute("sentry.sdk.name", name);
}
if ((sdk.Version ?? SdkVersion.Instance.Version) is { } version)
{
    SetAttribute("sentry.sdk.version", version);
}

A few things make this the right shape. It fixes logs and metrics in one edit because both funnel through here, so the two call sites cannot drift apart. It does not override anyone: when ASP.NET Core has set scope.Sdk.Name, that value is non-null so the ?? short circuits and the integration still wins. SdkVersion.Instance is the same object the envelope header already uses, so logs and metrics now agree with the envelope instead of contradicting it.

Test first, watch it fail, then pass

Two new tests reproduce the console path. The log one:

[Fact]
public void SetDefaultAttributes_EmptyScopeSdk_UsesSdkInstance()
{
    var options = new SentryOptions();
    var log = new SentryLog(Timestamp, TraceId, SentryLogLevel.Info, "message");

    // A console app does not populate scope.Sdk, so its Name and Version stay null.
    log.SetDefaultAttributes(options, new Scope(options));

    SdkVersion.Instance.Version.Should().NotBeNullOrWhiteSpace();
    log.Attributes.ShouldContain("sentry.sdk.name", "sentry.dotnet");
    log.Attributes.ShouldContain("sentry.sdk.version", SdkVersion.Instance.Version);
}

The metric one mirrors it with new SdkVersion(), which is what the metric path receives in a console app. Two existing serialization tests were pinning the buggy payload (no SDK attributes), so they are corrected to include the name and version.

Revert only the source file and keep the tests: the suite reports Failed: 4, Passed: 2529. The two new tests fail on the missing sentry.sdk.name, plus the two corrected serialization tests. Put the one-line fix back and it is Failed: 0, Passed: 2533, Skipped: 5, Total: 2538 on net10.0. dotnet format --verify-no-changes is clean on the changed files. The pre-existing Protocol_Default_VerifyAttributes tests never caught the bug because they pre-populate the Sdk, so they never touch the empty case.

The change

This is a fix inside the Sentry .NET SDK itself, not an app that uses it. Issue #5352, pull request getsentry/sentry-dotnet#5483, branch fix/sdkversion-empty-for-console at commit 36a0d63. One line of source in SentryAttributes.cs plus the regression tests. A dead ?? fallback that everyone assumed was covering the empty case, sitting one property away from the fix.

Best Use of Sentry

This entry is in two Bug Smash categories. Clear the Lineup covers the fix itself. Best Use of Sentry fits because the fix lives inside Sentry's own SDK. sentry.sdk.name and sentry.sdk.version are the attribution layer of the telemetry pipeline. They are how the platform knows a log or a metric came from sentry.dotnet and which version produced it, which is what lets Sentry group data by SDK, spot version-specific regressions and route an issue to the right maintainers. When a console app drops them, its logs and metrics arrive unattributed. The ASP.NET Core path silently disagreeing with it made the gap easy to miss. Restoring the fields at the one method both paths share means every log and every metric now carries the same SDK identity the envelope header already sends, so the data a team relies on to debug production lines up with itself.

AI disclosure

AI assistance (Claude, Anthropic) was used to trace the root cause, write the fix and the tests, then run the test suite. I own the change, reviewed it and verified it locally before submitting. Verified: the full Sentry.Tests suite on net10.0 (2533 passing, 0 failing); the bug reproduced by reverting only the source file (4 failing); dotnet format --verify-no-changes clean on the changed files.

The .git substring that broke but pr new for GitHub Pages repos

Asuran — Thu, 13 Aug 2026 01:32:50 +0000

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

The bug that only bites `.github.io` repos

Someone opened issue #15302 on GitButler with a clean report: running but pr new in their repo failed with HTTP 404 and the message "Failed to list open pull requests". Their remote was a GitHub Pages repo:

git@github.com:bburns-ds/bburns-test.github.io.git

That is a completely ordinary clone URL. Nothing exotic. So why would GitButler be unable to list pull requests for a real repository the user clones every day?

Following the 404

but pr new has to turn a remote URL into an (owner, repo) pair before it can call the GitHub API. I traced the path through the crates:

but pr new calls but_forge::derive_forge_repo_info(&remote_url).
list_forge_reviews pulls owner and repo out of that and calls but_github's pull request list.
That ends at list_open_pulls, which issues GET /repos/{owner}/{repo}/pulls.

So the 404 is GitHub telling us the request went to a repository that does not exist. The interesting question is what derive_forge_repo_info produced for a .github.io URL. I parsed the reporter's URL and got back repo = "org". Not org.github.io. Just org. The API call had become GET /repos/org/org/pulls, which of course 404s.

The `.git` substring trap

derive_forge_repo_info parses the URL with the git-url-parse crate. Here is the exact code that splits the path, from git-url-parse 0.6.0 (src/types/provider/generic.rs):

let (input, (user, repo)) = if input.ends_with(".git") {
    separated_pair(is_not("/"), tag("/"), take_until(".git")).parse(input)?
} else {
    separated_pair(is_not("/"), tag("/"), is_not("/")).parse(input)?
};

Read the .ends_with(".git") branch closely. It reads the repo name with take_until(".git"). take_until stops at the first .git substring, not the terminal suffix. Most repo names never contain .git, so this is invisible almost all the time. But a GitHub Pages repo is named something.github.io, where the .github piece contains .git. So the path org/org.github.io.git gets cut at the .git inside .github and the repo name collapses to org.

The trap only springs when two things line up: the URL ends in the .git clone suffix AND the repo name contains .git earlier. Canonical GitHub clone URLs always append .git, so every Pages repo hits it. I confirmed the full parse matrix in a scratch crate against git-url-parse 0.6.0:

remote URL	parsed repo	should be
`git@github.com:org/repo.git`	repo	repo
`git@github.com:org/org.github.io`	org.github.io	org.github.io
`git@github.com:org/org.github.io.git`	org	org.github.io
`https://github.com/org/org.github.io.git`	org	org.github.io

Only the rows that carry both the suffix and the substring are wrong.

The fix

The buggy line lives inside a published dependency, so I cannot edit it. But I can stop feeding it the input that trips it. Look at the else branch above: for a URL that does NOT end in .git, the parser uses is_not("/"), which reads the whole repo name up to the next slash and keeps org.github.io intact.

So the fix is to strip a single trailing .git at our boundary, before parsing, in crates/but-forge/src/lib.rs:

Before:

pub fn derive_forge_repo_info(url: &str) -> Option<ForgeRepoInfo> {
    let git_url = GitUrl::parse(url).ok()?;

After:

pub fn derive_forge_repo_info(url: &str) -> Option<ForgeRepoInfo> {
    // git-url-parse 0.6.0's GenericProvider strips the git-suffix with
    // `take_until(".git")`, which stops at the FIRST ".git" substring rather
    // than the terminal suffix. So `org/org.github.io.git` yields repo="org"
    // and every URL built from it points at the wrong repository and 404s.
    // Strip a single trailing ".git" ourselves so the parser takes its correct
    // `is_not("/")` branch. Safe because a real repo name can't end in ".git".
    let url = url.strip_suffix(".git").unwrap_or(url);
    let git_url = GitUrl::parse(url).ok()?;

strip_suffix matters here. It removes exactly one trailing occurrence, which is the single .git clone suffix GitHub appends. Using replace(".git", "") would delete the .git inside .github and recreate the bug. It is safe to strip because GitHub does not allow a repo name to end in .git, so a trailing .git is always the clone suffix. SSH and HTTPS URLs are handled the same way because the strip runs on the raw string. The same (owner, repo) also feeds the web base URL and the commit, PR and compare links, so those are fixed too.

The test, failing then passing

I added a table-driven regression test, repo_name_containing_dotgit_is_parsed_correctly, that asserts forge, owner and repo for nine URL cases: SSH and HTTPS, each plain and with .git, plus the *.github.io family with and without the suffix.

With the fix reverted and the test kept, the suite fails on exactly the reported case:

---- tests::repo_name_containing_dotgit_is_parsed_correctly stdout ----
assertion `left == right` failed: repo for git@github.com:org/org.github.io.git
  left: "org"
 right: "org.github.io"

test result: FAILED. 103 passed; 1 failed

With the one-line fix in place, everything is green:

test tests::repo_name_containing_dotgit_is_parsed_correctly ... ok
test result: ok. 104 passed; 0 failed

That before/after pair is the proof: the test catches the real defect and the single line is what resolves it.

Verification

cargo test -p but-forge with the fix: 104 passed, 0 failed.
Same run with the fix removed: 103 passed, 1 failed on the target case.
cargo clippy -p but-forge --all-targets: 0 warnings.
cargo fmt -- --check: clean.

AI disclosure

AI assistance (Claude, Anthropic) was used while working on this fix. I did the diagnosis, the design, the review and the verification. I own the change. What was verified locally before submitting: cargo test -p but-forge (104 passed, plus the new test fails 1 of 104 with the fix reverted), cargo clippy -p but-forge --all-targets (0 warnings) and cargo fmt -- --check (clean).

A single failed flush was silently killing telemetry in the Sentry Python SDK

Asuran — Wed, 12 Aug 2026 08:45:27 +0000

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

Project Overview

This entry is a real, tested bug fix in the Sentry Python SDK for issue #7138. The SDK batches logs, metrics and spans and ships them from a background daemon thread. If one flush ever raised, that thread died. From then on the process kept buffering telemetry that was never sent and eventually dropped. No error reached the application. The fix makes the flush loop tolerate a failed batch and keep running.

Bug Fix or Performance Improvement

Sentry's SDK does not send every log or span the moment you create it. It buffers them in a Batcher and a background daemon thread drains the buffer on a timer. That thread runs a simple loop: wait, then flush.

def _flush_loop(self):
    self._active.flag = True
    while self._running:
        self._flush_event.wait(self.FLUSH_WAIT_TIME + random.random())
        self._flush_event.clear()
        self._flush()   # nothing catches an exception here

_flush() serializes the buffered items and hands them to the transport. If any part of that raised, the exception propagated straight out of _flush_loop. Because this is the thread's entry point, the thread ended. Python does not restart it.

The quiet part is what happens next. add() decides whether to start the flusher by checking _flusher_pid == os.getpid(). After the thread has died that check still passes, because the pid never changed, so add() happily keeps appending to a buffer that nothing drains. Items pile up until the buffer hits its hard cap (MAX_BEFORE_DROP, 1000 for logs). Every item after that is dropped through _record_lost. So a single transient error inside one flush turns into permanent, silent telemetry loss for the rest of the process lifetime. On a long-lived web worker the whole point of running the SDK is gone, with nothing in the logs to say why.

The issue was filed with a concrete trigger: a RuntimeError: _core::PyFeatureContext is unsendable ... raised while serializing a value during a flush. But the class of the bug is broader than any one trigger. The batcher sits on the SDK's own hot path and must not let one bad item take down the sender.

Code

The fix follows the issue title exactly: tolerate exceptions in the flush loop. Each loop wraps its flush in capture_internal_exceptions(), the SDK's own context manager for errors that are the SDK's own fault and should be logged rather than thrown at the user.

from sentry_sdk.utils import capture_internal_exceptions, format_timestamp

def _flush_loop(self):
    self._active.flag = True
    while self._running:
        self._flush_event.wait(self.FLUSH_WAIT_TIME + random.random())
        self._flush_event.clear()
        with capture_internal_exceptions():
            self._flush()

The same guard goes on SpanBatcher._flush_loop, which has two flush calls (the pending-buckets flush and the periodic full flush), so all three batchers are covered: logs and metrics through the base Batcher, spans through the SpanBatcher override. A failed batch is now swallowed and logged. The loop stays alive and the next flush delivers everything that queued up in the meantime.

PR: getsentry/sentry-python#7186, from branch fix/tolerate-exceptions-in-flush-loop on my fork. sentry-python's bot auto-closes PRs opened before a maintainer agrees on the issue, so the change was staked on the issue thread first. Once a maintainer confirmed the direction there, the branch was rebased onto current master and the PR opened.

My Improvements

The diff is small and on point: four files, +94 / -15, with the real source change being the two with capture_internal_exceptions(): guards. The rest is comments and tests.

I added one regression test per loop, test_flush_loop_swallows_flush_exception, in tests/test_logs.py (base Batcher) and tests/tracing/test_span_batcher.py (SpanBatcher). Each builds a batcher whose _flush raises once and then stops the loop, calls _flush_loop() directly on the main thread and asserts it returns instead of raising. Run against the unfixed source both fail with RuntimeError: boom in flush, which is exactly the propagation that killed the real thread. With the fix both pass. They carry the repo's own @pytest.mark.tests_internal_exceptions marker, the suite's opt-in for tests that exercise capture_internal_exceptions, which is a nice confirmation that the fix routes through the SDK's standard internal-error handling rather than a bespoke try/except.

Verification, all green: 73 passed across the logs, metrics and span-batcher suites, ruff check and ruff format --check clean on the changed files, mypy sentry_sdk shows no new errors versus the base (its 28 pre-existing errors are all in an unrelated integration, none in the batcher files).

Best Use of Sentry

This is a fix to Sentry's own delivery pipeline, the part every log, metric and span passes through on its way out. The failure mode it removes is the worst kind for an observability tool: the SDK stops reporting and never says so, so the first you know is a gap in your dashboards during an incident. Making the flush loop survive a single bad batch means the SDK degrades to "log the internal error and keep going" instead of "go silent forever," which is the behavior you want from the thing you rely on to tell you when everything else is broken.

AI disclosure

AI assistance (Claude, Anthropic) was used in developing this change. The design, review and verification were done by the author. Verified locally before submitting: the two new regression tests fail on the unpatched source and pass with the fix, the logs, metrics and span-batcher suites pass (73 tests), ruff check and ruff format --check are clean on the changed files, mypy sentry_sdk shows no new errors versus the base.