DEV Community: Asuran

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.

Stop the event loop stall: a Sentry Python SDK fix for slow local-variable capture

Asuran — Wed, 12 Aug 2026 06:11:42 +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 #6649. On FastAPI 0.137 and newer, logging a single exception could freeze an async service for seconds because Sentry was building a giant text representation of the framework's internal router objects while capturing stack-frame locals. The fix makes that capture bounded and fast without changing what data ends up in Sentry for normal cases.

Bug Fix or Performance Improvement

When Sentry captures an exception with include_local_variables=True (the default), it serializes every stack frame's local variables. For any value that is not a plain container it falls back to Python's repr(), builds the whole string, then truncates it. That is fine for small objects. It is not fine when the object's repr() walks a large graph.

FastAPI 0.137 stopped flattening routes on include_router(). Each nested routing frame now holds a fastapi.routing._IncludedRouter, a dataclass whose auto-generated __repr__ recurses through the entire router tree. The same object shows up as self, route and included_router in every nested frame, so Sentry paid for that whole-app repr() over and over. Measured locally at 800 routes, one _IncludedRouter repr is 1,782,273 characters. In production at thousands of routes the reporter saw about 20 seconds per logged error, long enough to trip the gunicorn UvicornWorker timeout and get the worker killed. On an async app this blocks the event loop the whole time.

The cost is building the string, not storing it, so simply capping the output length does not help. Neither does reprlib (it still calls the object's full repr() first). The fix has to avoid materializing the graph in the first place.

Here is the wall time of one logger.error(..., exc_info=exc) with locals on, by route count, before and after:

routes	before	after
200	0.180s	0.121s
400	0.385s	0.120s
800	0.768s	0.121s
1600	1.553s	0.131s

Before, the time grows linearly with the size of the app. After, it is flat, so it no longer scales with the router graph. The per-frame local serialization at 800 routes drops from 0.303s to 0.008s, about 38x.

Code

The fix, as a PR: getsentry/sentry-python#7176, which a maintainer invited on #6649. Branch fix/logging-locals-serialization-eventloop-stall, commit 73f8f54.

The core of the fix is a new bounded_repr() in sentry_sdk/utils.py. It renders dataclass fields and the standard container types itself and stops the moment the output reaches the budget, so it never calls the object's own recursive __repr__ on a large graph.

def bounded_repr(value, max_length):
    """repr(value) that stops once the output would exceed max_length.

    Renders dataclass fields and standard containers itself and stops as
    soon as the output reaches max_length, returning a prefix of repr(value)
    followed by "...". When the full repr fits, the result is byte-for-byte
    identical to repr(value). Leaf values (strings, numbers, objects with a
    custom __repr__) are always rendered in full, so string values are never
    shortened; only over-large container/dataclass graphs are cut.
    """
    if max_length is None:
        return safe_repr(value)

    chunks = []
    total = 0

    def emit(text):
        nonlocal total
        chunks.append(text)
        total += len(text)

    def render(obj, depth):
        if depth > _MAX_BOUNDED_REPR_DEPTH:
            emit("...")
            return
        if dataclasses.is_dataclass(obj) and not isinstance(obj, type):
            items = (
                (field.name + "=", getattr(obj, field.name))
                for field in dataclasses.fields(obj)
                if field.repr
            )
            _render_items(type(obj).__qualname__ + "(", ")", items, depth)
            return
        obj_type = type(obj)
        if obj_type is dict:
            _render_items("{", "}", ((safe_repr(k) + ": ", v) for k, v in obj.items()), depth)
        elif obj_type is list:
            _render_items("[", "]", (("", v) for v in obj), depth)
        # tuple / set / frozenset handled the same way ...
        else:
            emit(safe_repr(obj))

    def _render_items(opening, closing, items, depth):
        emit(opening)
        first = True
        for prefix, child in items:
            if total >= max_length:
                raise _BoundedReprLimit  # what we emitted is a real prefix of repr(value)
            if not first:
                emit(", ")
            first = False
            emit(prefix)
            render(child, depth + 1)
        emit(closing)

    try:
        render(value, 0)
    except _BoundedReprLimit:
        chunks.append("...")
    return "".join(chunks)

The serializer then uses it from the same place it used safe_repr, so custom_repr still runs first, capped at max_value_length when set and otherwise at a generous default:

def _safe_repr_wrapper(self, value):
    try:
        repr_value = None
        if self.custom_repr is not None:
            repr_value = self.custom_repr(value)
        return repr_value or bounded_repr(value, self._max_repr_length())
    except Exception:
        return safe_repr(value)

My Improvements

The change is small and focused: three files, +198 / -2. It keeps the captured data the same for normal cases and only bounds the pathological one.

What it preserves: when a value's full repr() fits within the budget the result is byte-for-byte identical to repr(), verified over 3000+ randomized nested structures with zero mismatches. Leaf strings are always rendered in full, so the "keep long strings" behavior from a recent SDK change stays intact. There is no FastAPI-specific code, so the maintainer's concern about a special case clashing with custom_repr does not apply.

Three tests were added to tests/test_serializer.py: one that a small object still serializes to its exact repr(), one that a large object is not fully materialized (a sentinel placed after an oversized field is never reached, so reverting the fix trips it), one that with max_value_length set the output matches the old build-then-truncate result. Verification, all green: 230 passed and 2 skipped across the serializer, utils and logging suites, ruff check and ruff format --check clean on the changed files, mypy sentry_sdk shows no new errors versus the base.

Best Use of Sentry

The best use of Sentry here is making Sentry itself better for every async Python service that uses it. Error capture should never be the thing that takes a service down. On modern FastAPI this bug could turn a normal 500 into a killed worker. This fix keeps Sentry's rich local-variable capture (which is genuinely useful for debugging) while making its cost bounded and predictable, so teams can leave include_local_variables=True on in production without risking event-loop stalls. It also hardens the serializer against any object whose repr() walks a large graph, not just FastAPI's, which is exactly the general limit the maintainers said they wanted.

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 new and existing serializer, utils and logging tests pass, ruff check and ruff format --check are clean on the changed files, mypy sentry_sdk shows no new errors versus the base.

Surfacing swallowed provider errors in the Sentry MCP test client

Asuran — Wed, 12 Aug 2026 05:38:45 +0000

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

Project Overview

Sentry MCP is a Model Context Protocol server that exposes Sentry's error and performance data to AI assistants. It ships a small CLI test client (packages/mcp-test-client) that drives the server through a real LLM so you can exercise the tools end to end. This fix lands in runAgent inside that test client. It closes issue #500, which was filed by Sentry's founder.

Bug Fix or Performance Improvement

When the client hit a provider error (an invalid API key, a rate limit or a 5xx), it printed (No response generated) and moved on. The real reason was lost. The cause is a detail of the Vercel AI SDK the repo pins (ai@6): streamText does not throw when the request fails. It ends textStream with zero chunks and reports the failure only through an onError callback the code never set. So the for await loop finished empty, runAgent never entered its catch, the Sentry span kept its OK status and nothing was captured. The client then fell through to the misleading empty-response message. The failure was invisible to the user and to Sentry at the same time. I confirmed this against the installed SDK before writing anything: a probe showed textStream yields zero chunks without throwing, while onError fires with an APICallError carrying statusCode: 401. The issue guessed the error might sit on result.errorPromise; on this SDK version that property does not exist, so the fix does not use it.

Code

The fix, merged: getsentry/sentry-mcp#1243 was merged into getsentry/sentry-mcp by the maintainer who filed the issue, branch fix/mcp-test-client-surface-provider-errors.

The client now captures what the SDK reports through onError, then surfaces it once the stream drains so it flows through the existing catch:

let streamError: unknown;

const result = await streamText({
  model: languageModel,
  system: SYSTEM_PROMPT,
  messages: [{ role: "user", content: userPrompt }],
  tools,
  stopWhen: stepCountIs(maxSteps),
  experimental_telemetry: { isEnabled: true },
  onError: ({ error }) => {
    // Provider failures arrive here rather than as a thrown error.
    streamError = error;
  },
  onStepFinish: (/* ... */) => { /* ... */ },
});

for await (const chunk of result.textStream) {
  /* ... stream chunks to the terminal ... */
}

// Surface the provider failure instead of the silent fallback. Throwing
// routes it through the catch, which marks the span errored and rethrows.
if (streamError !== undefined) {
  if (isStreaming) {
    logStreamEnd();
    isStreaming = false;
  }
  throw new Error(describeProviderError(streamError, provider), {
    cause: streamError,
  });
}

The mapper turns the raw error into the message the issue asked for. It also unwraps a RetryError, because retryable statuses (429 and 5xx) are retried by the SDK and then delivered wrapped, with the HTTP status on lastError:

export function describeProviderError(error, provider) {
  const label = provider === "openrouter" ? "OpenRouter API" : "OpenAI API";
  const envVar =
    provider === "openrouter" ? "OPENROUTER_API_KEY" : "OPENAI_API_KEY";

  const apiError = findApiCallError(error); // unwraps RetryError / cause
  if (apiError) {
    const status = apiError.statusCode;
    if (status === 401 || status === 403)
      return `${label} authentication failed. Please check your ${envVar} environment variable.`;
    if (status === 429)
      return `${label} rate limit exceeded. Please wait and try again.`;
    if (status !== undefined && status >= 500)
      return `${label} service error. The service may be temporarily unavailable.`;
    return `${label} request failed${status ? ` (HTTP ${status})` : ""}: ${apiError.message}`;
  }
  const message = error instanceof Error ? error.message : String(error);
  return `${label} request failed: ${message}`;
}

My Improvements

The behavior change is small on purpose. A provider error now produces a clear, provider-aware message that names the environment variable to check. The legitimate empty-response path is untouched, so a genuine empty reply still reads (No response generated). I added nine tests. Integration tests through runAgent prove a 401 stream surfaces the auth message, rejects and does not print the fallback. They also prove a real 429 (driven through the SDK's actual retry path, so a real RetryError) surfaces the rate limit message. Unit tests cover the full mapping: 401, 403, 429, 5xx, the RetryError unwrap, a generic 400 and a non-API error. To keep the fix honest I reverted only the source change and watched the new tests fail, then restored it and watched them pass. The package suite goes from 70 to 79 passing. Type-check, Biome lint and format plus ast-grep are all green on the changed package.

Best Use of Sentry

The whole point of the fix is that Sentry can finally see the failure. runAgent wraps its work in a Sentry span; before the fix that span stayed OK on a provider error and no event was captured. Now the thrown error runs through the catch, which calls span.setStatus({ code: 2 }) and rethrows, so the top-level Sentry.captureException in the CLI records it and the cause carries the original APICallError for full context. I proved this with a real send to a Sentry DSN: the harness stubs a 401 (no real model call is placed), runs the real runAgent and logs through beforeSend and beforeSendTransaction exactly what leaves the process. Before the fix, the root span status transmitted is ok and no exception event is sent. After the fix, a real exception event is captured and the root span status transmitted is internal_error. The same before and after is also enforced offline by span-status assertions in the test suite, so the guarantee does not depend on the network.

The same failure, now a real Sentry issue (environment bugsmash-issue-500-demo, level error). The stack trace shows the fix's own code: the throw new Error(describeProviderError(...)) that routes the error through the catch so Sentry records it. Before the fix this printed (No response generated) and no event reached Sentry at all.

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 @sentry/mcp-test-client vitest suite (79 passing, up from 70), tsc --noEmit for the package, Biome lint and format, ast-grep, plus a real Sentry send showing the error now reaches Sentry with the span marked errored.

DEV Community: Asuran

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

A whole class of tests cannot fail

Why review misses it

Finding them

The fastify case

The takeaway

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

So the tool reads the checks rather than the code

Proof mode, because a scanner should not be believed either

It runs in CI and posts on the pull request

What it does to itself

What it will not do

Try it on something you own

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

What the false positive looked like

The part that actually scared me

The two fixes

Verification

What I would tell my past self

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

What I Built

Demo

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

What it does

How I Built It

Prize Categories

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

The bug

Bug Fix or Performance Improvement

My Improvements

Best Use of Sentry

Best Use of Google AI

AI disclosure

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

The bug

Following the value

The fix

Proving it on real traffic

The hidden svg Biome flagged anyway: a noSvgWithoutTitle false positive

The bug

Following the value

The fix

Watch it fail, then pass

The change

AI disclosure

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

The bug that only showed up in console apps

Following the value

Why ASP.NET Core escaped

The fix

Test first, watch it fail, then pass

The change

Best Use of Sentry

AI disclosure

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

The bug that only bites .github.io repos

Following the 404

The .git substring trap

The fix

The test, failing then passing

Verification

Links

AI disclosure

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

Project Overview

Bug Fix or Performance Improvement

Code

My Improvements

Best Use of Sentry

AI disclosure

Stop the event loop stall: a Sentry Python SDK fix for slow local-variable capture

Project Overview

Bug Fix or Performance Improvement

Code

My Improvements

Best Use of Sentry

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

The `.git` substring trap