DEV Community: LubuSeb

I Built a Snowflake Search Desk for Missing Dogs. Its Most Important Result Is "No Match."

LubuSeb — Fri, 14 Aug 2026 20:37:03 +0000

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

AI disclosure: I used Codex extensively to implement, test and review this project, and to draft this post. I verified the public build, the live Snowflake execution and every numerical claim below.

What I Built

When a dog goes missing, the words used by owners and shelters rarely line up perfectly. "Gray" may arrive as "silver." "Border Collie mix" may be recorded as "Border Collie." A nearby intake can be easy to miss.

A weak resemblance can also create false hope.

I built Bark Back Home, a missing-dog search desk that compares a structured report with Austin Animal Center's public intake data. It returns a short ranked list, explains every point in the score and refuses to select a candidate when evidence is weak, conflicting or too close to another result.

The three sample missing-dog reports are fictional. The app does not collect owner names, contact details, photos or exact home addresses. Shelter candidates come from public records, but a ranked result is never presented as an identification.

Bark Back Home can say which public record deserves human review. It cannot say that the shelter dog is yours.

Demo

The hosted demo is deliberately fixture-only. It never receives a Snowflake key and cannot create warehouse spend. Its header and every result label say Offline fixture.

The live acceptance run exercised the same application API against Snowflake through a local, least-privilege service. The main report was Luna: a fictional male, black-and-white Border Collie mix last seen in ZIP 78613. Snowflake ranked public intake record 31498 first with a score of 100.

The interface exposes the breed, color, sex, location and timing contributions instead of reducing the result to an unexplained confidence number. The record still needs to be checked with the shelter using its public animal ID.

The live Snowflake search produced query ID 01c66412-0005-6537-0000-0001966e91b9; its four-source lineage query was 01c66413-0005-642d-0000-0001966e71c9.

I then ran Scout, the fictional negative control. The leading live candidate scored 65.3, below the automatic threshold of 78, and had conflicting breed evidence. Snowflake selected no candidate. The hosted fixture makes the same behavior easy to replay with a harsher contradiction:

That is the result I care about most. A matching system should demonstrate not only what it can retrieve, but also when it will stop.

Code

Source code, tests and reproduction instructions

The application uses React and TypeScript for the case-file interface, an Express API, the Snowflake Node SDK with key-pair authentication, and checked-in SQL for setup, loading, modeling, contracts and parameterized ranking.

The repository's first commit was made on August 14 after the challenge opened. The final gate includes 62 tests across nine files, TypeScript checking, a production build and a dependency audit with zero known vulnerabilities. GitHub Actions independently reruns the complete gate before deploying the fixture demo.

How I Built It

Snowflake is the matching system, not a database logo attached afterward.

The live run loaded four City of Austin feeds:

Feed	Rows
Current intakes	5,586
Current outcomes	5,643
Historical intakes	94,608
Historical outcomes	94,505
Total	200,342

Snowflake normalizes breed, color, sex, ZIP and timestamps. It removes current intakes that have a later outcome, calculates historical return-to-owner context and produced 551 unresolved current dog records for this run.

Each candidate receives inspectable contributions:

Factor	Weight
Breed	32
Color	20
Location	18
Sex	16
Time	14

A high aggregate score is not enough. Automatic selection also requires at least 60% evidence coverage, no hard chronology or known-sex conflict, and an eight-point lead over the runner-up. Snowflake performs retrieval and ranking. The shared application matcher checks the safety gates again before the interface can show a possible match.

The first live model execution found a real integration bug. Snowflake inferred NUMBER(16,6) inside a SQL function declared to return FLOAT. Explicitly casting the complete result repaired the function. The automated gate stayed green, and the live model then passed all 17 SQL contracts: four timezone cases, four ZIP-extraction cases and nine breed/color parity cases.

I used separate review passes to challenge the matcher, current public-feed schema, privacy boundary and live Snowflake path. A finding counted only when it could be reproduced as a test, SQL contract or browser-visible failure.

The API authenticates with an encrypted key pair through the dedicated BARK_BACK_HOME_APP role. Query history showed both searches and both lineage queries completing under that role:

A direct application-role query against a raw ingest table was denied. The public-facing path can read modeled views and functions, not the staged raw payloads.

The current refresh is intentionally modest: validated truncate-and-copy loading for a private hackathon demonstration. A continuously operated service should replace it with shadow tables and an atomic swap.

Prize Categories

Best Use of Snowflake

This is the only technology category I am entering.

Snowflake performs the central work: loading four public datasets, normalizing inconsistent descriptions, filtering resolved records, calculating historical context, ranking candidates and retaining query and lineage receipts for the answer shown to the user.

Without Snowflake, Bark Back Home is a case-file interface. With Snowflake, it becomes an explainable public-record search desk, including the ability to say that the responsible answer is to keep looking.

One Event-Loop Turn, One False Redis Capacity Error

LubuSeb — Sun, 09 Aug 2026 13:37:02 +0000

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

Project Overview

redis-py is the Python client for Redis. Its asynchronous cluster implementation maintains a per-node connection pool with an in-use set, a free queue, and optional max_connections capacity.

The bug was not a leaked connection or a deadlock. It was one event-loop turn in which a usable pool slot existed in neither place.

Bug Fix or Performance Improvement

An active async cluster connection can be marked for reconnect while a previous disconnect is still waiting for the socket to close. The disconnect clears the reconnect flag before it suspends, but another error or maintenance notification can mark the connection again during that wait.

By the time ClusterNode.release() receives it, the connection is closed but marked again.

The old release path treated every marked connection the same:

if connection.should_reconnect():
    task = asyncio.create_task(self._disconnect_and_release(connection))
    self._background_tasks.add(task)
    task.add_done_callback(self._background_tasks.discard)
    return
self._free.append(connection)

For an already-closed connection, the second disconnect performs no I/O. Its only useful operation is appending the connection to _free, and that operation is deferred until the background task runs.

At max_connections=1, a concurrent acquire in that gap sees:

_free is empty
len(_connections) == max_connections

and raises MaxConnectionsError. Capacity is about to return, but the caller receives a real application error first.

Code

The diagnosis and proposed directions came from petyaslavova in issue #4247. She traced the ownership gap, identified the reachable re-marking triggers, and suggested either returning an already-closed connection inline or making release() async.

My contribution in redis-py PR #4256 was to implement the smaller guarded fix and add a deterministic regression test through the real execute_command() path.

The repaired branch keeps the background disconnect for connections that are still open. If the connection is already closed, it clears the stale flag and returns the slot immediately:

if connection.should_reconnect():
    if connection.is_connected:
        task = asyncio.create_task(self._disconnect_and_release(connection))
        self._background_tasks.add(task)
        task.add_done_callback(self._background_tasks.discard)
        return
    connection.reset_should_reconnect()
self._free.append(connection)

This preserves the safety rule that a marked, connected socket must never go back into circulation. It also avoids scheduling a no-op disconnect for one that is already closed.

My Improvements

Reproduce the race through the real command path

A test that manually set two flags and called release() would prove the branch, but not that production control flow can reach it. The regression test instead drives ClusterNode.execute_command() with a scripted connection and uses asyncio.Event objects to control the interleaving:

Start sending the command.
Mark active connections for reconnect.
Let the response complete so the normal error path starts disconnecting.
Wait until the disconnect has suspended.
Mark the same connection again.
Allow the disconnect to finish.
Acquire the next connection immediately.

The final assertions check the behavior that matters:

assert node.acquire_connection() is connection
assert node._background_tasks == set()
assert connection.should_reconnect() is False
assert connection.disconnect_calls == 1

Before the fix, that acquire can hit the transient false-capacity window and the release path schedules a redundant second disconnect. After the fix, the same connection is available inline.

Prefer the narrow invariant repair

One alternative was to add a waiting acquisition API and turn more of the pool surface asynchronous. That would change public behavior and add coordination around a symptom.

The smaller fix restores the existing pool invariant: once a closed connection is released, it should be reusable immediately. No new public method, retry policy, timeout, or queue is required.

Keep the scope honest

This affects the async cluster pool when a node is at an explicitly configured connection limit and a reconnect mark lands during disconnect. It does not affect the synchronous cluster pool or the standalone pools. It causes a transient spurious MaxConnectionsError, not a permanent client hang.

The focused cluster connection-handling suite passed 13 tests on Windows and Ubuntu WSL. The changed code passed the repository's lint task, Ruff checks, formatting, vulture, and git diff --check. Cursor Bugbot passed on the public PR. At publication time, the upstream GitHub Actions for CI, Docs CI, CodeQL, and spellcheck still awaited maintainer approval, so I did not yet treat the full repository matrix as passed.

Update, August 17, 2026: PR #4256 was approved and merged upstream as commit 3972275. All 368 GitHub checks in the final PR rollup succeeded.

Result

An already-closed, re-marked connection now returns to the free queue in the same release call. The pool no longer reports false exhaustion simply because a no-op background task has not received its event-loop turn yet.

Concurrency bugs are often described as timing problems, but the useful question is usually about ownership: at every suspension point, which structure owns the resource, and can another task observe a state in which nobody can use it? Here, the implementation changed 6 additions and 4 deletions in production code, while the larger part of the patch made the execute_command() regression deterministic.

AI disclosure: I used AI tooling to assist with this project and post.

When YouTube Changed the Header: Fixing Invidious's Gaming Channel

LubuSeb — Sun, 09 Aug 2026 13:35:30 +0000

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

Project Overview

Invidious is an open-source alternative front end for YouTube. Because it reads YouTube's internal response structures, it has to survive upstream payload changes that arrive without a stable public schema.

One long-running failure affected YouTube's auto-generated channels. Opening a channel such as Gaming could raise:

Missing hash key: "interactiveTabbedHeaderRenderer" (KeyError)

The report had been open for years, but the failure was still reproducible against YouTube's current Gaming payload.

Bug Fix or Performance Improvement

The parser assumed every auto-generated channel used this legacy header:

header.interactiveTabbedHeaderRenderer

YouTube's current response for the affected channel instead uses:

header.pageHeaderRenderer.content.pageHeaderViewModel

The title and avatar moved into new nested view models. Some metadata that existed in the legacy shape is optional or absent in the current one. A direct key lookup therefore crashed before Invidious could render the channel page.

There was a second edge case behind it: a selected YouTube tab can exist without a content key. The extractor treated selection as proof of content and raised another KeyError.

Code

The implementation and focused regression tests are in Invidious PR #5858, linked to the project's $30 bug bounty issue.

Instead of scattering optional lookups through get_about_info, I extracted one compatibility boundary:

def extract_auto_generated_channel_header(initdata, ucid)
  if header = initdata.dig?("header", "interactiveTabbedHeaderRenderer")
    # Parse the legacy shape.
  elsif header = initdata.dig?("header", "pageHeaderRenderer")
    header_view = header.dig?("content", "pageHeaderViewModel")
    # Parse the current shape with bounded fallbacks.
  else
    raise InfoException.new(
      "Could not extract channel header for #{ucid}: " \
      "expected interactiveTabbedHeaderRenderer or pageHeaderRenderer."
    )
  end
end

The caller now consumes one normalized result regardless of which upstream renderer arrived.

For the empty selected-tab case, the fix is intentionally smaller:

content = extract_selected_tab(target["tabs"])["content"]?
return raw_items if content.nil?

An empty selected tab is an empty result, not an exceptional parser state.

My Improvements

Preserve compatibility instead of chasing one payload

Replacing the legacy branch with the new one would have fixed today's Gaming channel while breaking instances that still receive the older renderer. The extractor explicitly supports both shapes, and both have regression fixtures.

Default only when data is missing

The current shape does not always provide the banner, description, badges, or microformat fields the old parser expected. Those values receive narrow fallbacks.

One detail mattered: familySafe: false must remain false. A truthy fallback would silently convert a real value into a default. The implementation distinguishes nil from false:

family_safe = initdata
  .dig?("microformat", "microformatDataRenderer", "familySafe")
  .try &.as_bool

is_family_friendly = family_safe.nil? ? true : family_safe

Validate the route, not only the helper

The focused fixtures cover:

the current pageHeaderRenderer title and avatar path
the legacy interactiveTabbedHeaderRenderer path
an explicit familySafe: false
a selected tab with no content

I then ran the full local suite: 167 examples, 0 failures. The production Docker image built, the target channel route returned HTTP 200 with the expected Gaming - Invidious title and visible channel data, and the API route returned HTTP 200.

At the time of this update, upstream CI is 10 of 12 checks green: lint, both AMD64 and ARM64 Docker builds, and Crystal 1.14 through 1.20. The Crystal 1.21 and nightly jobs stop on unrelated repository-wide deprecation warnings in the logger and static asset handler; neither warning touches this change.

Scope of the fix

This is not a complete fix for every auto-generated YouTube channel. The route I reproduced was Gaming, and PR #5858 handles the pageHeaderRenderer shape while keeping the legacy renderer working.

A follow-up investigation in issue #5868 found a third shape, carouselHeaderRenderer, on the Sports channel. PR #5869 extends the same extracted-function approach to that case and explicitly credits #5858 for the compatibility boundary and selected-tab guard. The accurate result here is that Gaming and other pageHeaderRenderer channels work again. Sports needs the follow-up.

Result

The current auto-generated Gaming channel loads instead of reaching the error template, while the legacy renderer remains supported.

The broader lesson is that resilient parsers need an explicit compatibility boundary. Optional chaining everywhere can suppress useful errors; hard-coded indexing everywhere turns routine upstream drift into an outage. Normalizing known shapes in one place gave this fix both a clear failure mode and a testable contract.

AI disclosure: I used AI tooling to assist with this project and post.

Fixing npmx's 502 for packages blocked by jsDelivr's 150 MB limit

LubuSeb — Sun, 09 Aug 2026 12:57:54 +0000

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

Project Overview

npmx.dev is a fast, modern browser for the npm registry. It lets developers browse package source files, compare versions, and inspect package information without leaving the browser.

I worked on npmx issue #2899. Opening the code or skills view for next@16.2.9 returned a 502 because npmx could not retrieve the package file list from jsDelivr.

The issue reporter, 314systems, had already done the important initial diagnosis. They identified that the package exceeded jsDelivr's configured 150 MB limit. I started from that finding, confirmed the 403 response, reproduced how it became a 502 inside npmx, and implemented a bounded fallback.

I am not claiming that Sentry discovered the cause. I used Sentry later to independently verify the runtime boundary and the behavior before and after the fix.

The issue was opened before the challenge, but the implementation and evidence work were completed during the contest period. The core fix and both final Sentry evidence-state commits are timestamped August 9, 2026.

Bug Fix or Performance Improvement

Before the fix, npmx had one provider for package file metadata and content: jsDelivr.

For an oversized package such as next@16.2.9, the sequence was:

npmx requested package metadata from jsDelivr.
jsDelivr returned 403.
npmx converted that upstream failure into a 502.
The code browser and related views stopped there.

I reproduced this against a production build from the baseline commit, 5be120b.

Production-build probe	Baseline result
File tree for `next@16.2.9`	502
`package.json` for `next@16.2.9`	502
File tree for a normal `vue` version	200

The fix keeps jsDelivr as the primary provider. If, and only if, jsDelivr returns 403, npmx retries the same metadata or file request through UNPKG.

After the fix:

Production-build probe	Fixed result
File tree for `next@16.2.9`	200, with 8,076 files
`package.json` for `next@16.2.9`	200
File tree for the same `vue` control	200 through jsDelivr, with no fallback

This is a functional fix, not a performance claim. The result is that a package refused by jsDelivr can still be browsed instead of producing a 502.

Code

Issue: npmx-dev/npmx.dev#2899
Core fix: 941bf209
Review follow-up: 098a59b6
Upstream pull request: npmx-dev/npmx.dev#3161
Baseline Sentry evidence state: bf0e0465
Fixed Sentry evidence state: c95e027e

The central provider decision is deliberately narrow:

async function fetchWithFallback(
  primaryUrl: string,
  fallbackUrl: string,
  signal?: AbortSignal,
): Promise<PackageFetchResult> {
  const primary = await fetch(primaryUrl, { signal })

  if (primary.status !== 403) {
    if (!primary.ok) await cancelResponseBody(primary)
    return { provider: 'jsdelivr', response: primary }
  }

  await cancelResponseBody(primary)

  const fallback = await fetch(fallbackUrl, { signal })
  if (!fallback.ok) await cancelResponseBody(fallback)

  return { provider: 'unpkg', response: fallback }
}

A 404, 500, or successful response from jsDelivr keeps its existing behavior. This is not a general retry for every failure.

UNPKG and jsDelivr return different metadata shapes, so changing the URL was only part of the work. jsDelivr provides a nested tree. UNPKG provides a flat file list. The fix validates the UNPKG response and converts it into the tree structure that the rest of npmx expects.

if (provider === 'unpkg') {
  const parsed = v.safeParse(UnpkgMetadataResponseSchema, payload)

  if (!parsed.success || parsed.output.package !== packageName) {
    throw invalidFileListError()
  }

  return {
    package: packageName,
    version,
    tree: convertUnpkgToFileTree(parsed.output.files),
  }
}

The core fix touches 18 files: 12 application or shared-code files and 6 test or fixture files. That breadth is necessary because the jsDelivr assumption was spread across several consumers:

File-tree metadata
Individual file content
Package comparisons
File comparisons
Skills processing
Raw-file links in the code viewer
Shared provider types and URL construction
Tests and route fixtures for those paths

A narrower patch to the visible package page would have left other routes failing on the same package.

The Sentry instrumentation is separate from the upstream fix. It exists only in evidence commits on my fork so I could compare controlled production builds without asking the npmx maintainers to accept challenge-specific monitoring code.

My Improvements

One fallback policy for every package-file consumer

I added shared helpers for package metadata and file requests. The code viewer, file tree, comparison routes, and skills path now follow the same provider policy.

Normal traffic still uses jsDelivr. Only a primary 403 activates UNPKG.

Strict metadata validation

The UNPKG response is treated as external input. The converter validates paths, sizes, integrity values, and the requested package name before creating the internal tree.

It also rejects duplicate paths and file-directory conflicts instead of silently accepting an ambiguous result.

Fixed processing limits

Supporting larger packages does not mean accepting unlimited metadata or file content.

The UNPKG metadata path has these fixed limits:

10 MiB maximum metadata response
50,000 files
100 path segments per file
250,000 total path segments

File bodies use a bounded streaming reader. The code viewer still limits highlighted source files to 500 KiB, while its package.json helper allows up to 2 MiB.

Those are intentional limits. A package with metadata beyond the new bounds will still fail safely, and a source file larger than the existing viewer limit will still not be rendered inline. The fix resolves the provider-level package failure. It does not remove every content-size restriction in npmx.

Fixed and encoded provider URLs

Package versions and individual path segments are encoded before being added to provider URLs. Provider origins are fixed in code rather than accepted from request input.

Raw-file viewer tradeoff

The raw-file buttons now link to UNPKG's file viewer. This makes raw access work for a package that jsDelivr refuses to serve.

The tradeoff is that the raw button uses UNPKG even when the in-app request succeeded through jsDelivr. The current API response does not expose the selected provider to the UI, so the link cannot switch dynamically without widening the public response shape.

I chose working raw access for oversized packages over keeping the raw link visually tied to the primary provider. This does add an UNPKG dependency to the raw-view action, but it does not change the primary server-fetch path for normal packages.

Regression coverage

The tests cover:

jsDelivr success without fallback
Fallback after a jsDelivr 403
File and metadata requests
Invalid UNPKG payloads
Duplicate paths and file-directory conflicts
Metadata, file-count, depth, and complexity limits
Bounded response reading
Scoped packages and encoded file paths
Existing normal-package behavior

The final core-fix validation included:

Check	Result
Unit suite	1,743 passing
Type checking	Passing
Linting	Passing
Production build	Passing
Focused package-code page tests	Passing
Live `next@16.2.9` production probe	200, 8,076 files
Normal `vue` control	200, no fallback
Browser check of the package-code page	Passing
Upstream pull request checks	All passing

Best Use of Sentry

I used Sentry Error Monitoring and custom server tracing to verify the runtime behavior of the existing failure and the fallback.

Again, Sentry did not discover jsDelivr's 150 MB limit. The reporter, 314systems, identified that cause. Sentry let me independently show what npmx did with the upstream response and whether the fix changed only the intended path.

Controlled before-and-after evidence

I instrumented two fork-only production states:

Baseline source: 5be120b
Baseline evidence state: bf0e0465
Fixed source: 941bf209
Final upstream PR head: 098a59b6
Fixed evidence state: c95e027e
Baseline release: npmx-2899-before-5be120b-clean
Fixed release: npmx-2899-after-941bf209-clean
Environment: bugsmash-local

Both states use @sentry/nuxt in production-build mode. Instrumentation is enabled only when BUGSMASH_SENTRY_ENABLED=true, and the DSN remains in an environment variable.

The hosted fixed-state evidence uses the core implementation at 941bf209. The later 098a59b6 review follow-up does not change the provider fallback. It preserves comparison aborts, clarifies size-limit errors, expands one comment, and adds a bounded-reader test.

I added custom server spans around the provider boundary. They record a small set of explicit attributes:

{
  'asset.kind': assetKind,
  'cdn.provider': provider,
  'cdn.role': role,
  'fallback.used': role === 'fallback',
  'npm.package': packageName,
  'npm.version': version,
  'source.commit': sourceCommit,
  'bugsmash.synthetic': true,
}

The provider span also records the HTTP status and whether a primary 403 triggered the fallback.

This is custom server tracing within one synthetic local service. I did not propagate traces to jsDelivr or UNPKG, so I am not describing it as distributed tracing.

What Error Monitoring showed before the fix

The baseline production request returned 502.

The local Sentry envelope capture contained:

The npmx error event
A custom jsDelivr provider transaction
HTTP status 403
Sentry status permission_denied
fallback.available: false
Matching trace IDs between the error event and provider transaction

Baseline hosted tree trace ID: 4de5891fa25248b58cd01be1f9a35975
Baseline hosted tree error event: 596c2d3547914b619f661223aa7e8eda
Baseline hosted file trace ID: 6a06a704a73148fba774f0ba87ee0797

What custom server tracing showed after the fix

The same production request returned 200 after the fix.

The local evidence run showed this sequence:

The jsDelivr primary metadata request returned 403.
The custom span recorded fallback.triggered: true.
The UNPKG fallback returned 200.
npmx converted the metadata into a tree containing 8,076 files.
The API request completed successfully.

The package-file route showed the same recovery for package.json.

The vue control stayed on jsDelivr and recorded no fallback. That control matters because it shows the fix did not redirect normal package traffic.

Fixed hosted tree trace ID: 564054b21cbb43c7b195cf3e08a17ba6
Fixed hosted file trace ID: 113024125b8641ed9dfecee823b33550

Control hosted trace ID: aaf98132b1014b6188ce8c30f22a04ea

Keeping the synthetic evidence small and private

These were synthetic local requests, but I still configured the SDK to collect as little request data as possible.

The evidence setup disables user information, cookies, request and response headers, bodies, query parameters, breadcrumbs, source maps, database query data, frame variables, and outgoing trace propagation. Request objects are removed before events are sent, and the custom evidence spans are marked as synthetic.

Sentry still derived coarse location labels on some child spans from the network ingress. The private dashboard retained those labels even though IP storage was disabled, so I kept the dashboard private and excluded those fields from every publishable screenshot.

I also scanned the captured raw envelopes. They did not contain local user paths, authorization values, cookies, user-agent values, IP addresses, or request and response headers.

Sentry's value here was verification. Error Monitoring preserved the baseline failure. Custom server tracing made the provider decision visible. Together they showed one failed provider becoming a controlled fallback and a successful response, while the normal control remained on the original path.

AI disclosure: I used AI tooling to assist with this project and post.

Building a 10.2x Faster Search-Only Retrieval Path on Arm64

LubuSeb — Sat, 08 Aug 2026 21:46:37 +0000

NeonRecall's best accepted native Arm64 workload showed a 10.214x three-run median throughput speedup over its FP32 retrieval baseline.

That number needs a clear boundary. This is a single-threaded, search-only benchmark over already-produced embeddings. It does not include model inference, embedding generation, index construction, or corpus and query quantization.

Within that boundary, the result was consistent across three vector widths:

Workload	Per-run speedups	Three-run median	INT8 / FP32 payload
384 dimensions	9.349x, 10.465x, 10.214x	10.214x	25.26%
768 dimensions	9.311x, 9.921x, 9.354x	9.354x	25.13%
1536 dimensions	4.988x, 9.243x, 7.517x	7.517x	25.07%

Every optimized run was faster and had lower p95 search latency. The benchmark ran on native Arm64 Linux and selected the aarch64-neon-dotprod kernel.

The problem I wanted to isolate

A semantic-retrieval service usually has at least two distinct stages:

A model turns text into embeddings.
A search layer compares a query embedding with stored document embeddings.

It is easy to mix the two and report a speedup that is hard to interpret. NeonRecall deliberately isolates the second stage.

Both benchmark paths receive the same deterministic vectors and use the same top-k ranking implementation. The difference is the representation and dot-product arithmetic:

The baseline stores and searches FP32 vectors.
The optimized path stores symmetric per-vector INT8 vectors and uses an Arm-specific integer dot product.

This makes the comparison narrow, but it also makes the result easier to audit.

Per-vector INT8 instead of FP32

Each FP32 vector is quantized independently. NeonRecall finds the vector's largest absolute value and derives one scale:

scale = max(abs(vector)) / 127
q[i]  = clamp(round(vector[i] / scale), -127, 127)

The index stores one signed byte per dimension plus one FP32 scale per vector. During search, the integer dot product is rescaled before ranking:

const std::int64_t integer_score =
    dot_int8_selected_impl(selected.kind, query.values, vectors[i].values);

scores[i] = static_cast<float>(integer_score)
          * query.scale
          * vectors[i].scale;

For these workloads, that representation used 25.1% to 25.3% of the FP32 encoded-vector payload. This is a payload comparison, not a claim about total process memory or container overhead.

Selecting the right Arm kernel at runtime

NeonRecall provides three INT8 paths:

A portable scalar implementation.
An AArch64 NEON widening implementation.
An AArch64 NEON dot-product implementation.

The binary checks the CPU at runtime and selects the strongest supported path:

if (!capabilities.is_aarch64 || !capabilities.neon) {
  return {KernelKind::ScalarInt8, "scalar-int8"};
}

if (capabilities.dotprod) {
  return {KernelKind::NeonDotProduct, "aarch64-neon-dotprod"};
}

return {KernelKind::NeonWidening, "aarch64-neon-widening"};

On a CPU with the dot-product extension, the hot loop processes 16 signed bytes at a time:

const int8x16_t left = vld1q_s8(lhs.data() + offset);
const int8x16_t right = vld1q_s8(rhs.data() + offset);
accumulator = vdotq_s32(accumulator, left, right);

The scalar path still matters. It gives the optimized representation a portable correctness reference, while runtime dispatch keeps the binary usable across different machines.

Measuring quality without overstating it

Quantization is only useful if retrieval remains acceptable, so the evidence pipeline includes a separate quality sanity check.

A revision-pinned qint8 MiniLM ONNX encoder produces one set of real embeddings. NeonRecall then compares FP32 retrieval arithmetic with INT8 retrieval arithmetic over those same embeddings.

Across three repetitions, both paths reached macro recall@10 of 1.0 on the included 18-document, six-query demo, with identical top-ten lists.

That is encouraging, but it is not a general retrieval-quality claim. It is a bounded regression check on a small authored dataset. It is also not a full-FP32 model versus INT8 model comparison; both retrieval paths use embeddings from the same pinned encoder.

The evidence pipeline is designed to reject bad runs

Performance work becomes much less convincing when the benchmark screenshot cannot be traced back to a binary, source commit, CPU, and exact input.

The accepted NeonRecall aggregate comes from three repetitions on a native ubuntu-24.04-arm GitHub Actions runner. Before accepting the result, the workflow:

verifies the source commit and uploaded binary hashes;
re-executes every uploaded binary on the aggregate runner;
confirms ELF64 little-endian AArch64 identity;
regenerates disassembly and requires the selected kernel's Arm instruction;
locks deterministic input fingerprints and cross-run checksums;
recomputes recall from raw ranked document IDs and repository qrels; and
rejects scalar dispatch, performance regressions, excessive payload, or recall below the documented threshold.

The public aggregate records commit 904c8bd7120ef419a68019ed5ab92f43bf49d55c, workflow run 29539633599, the selected kernel, the compiler, the model revision, every individual speedup, and the quality results.

Reproducing the short path

On native Arm64 Linux, the basic correctness and dispatch path is:

git clone https://github.com/LubuSeb/neonrecall-arm.git
cd neonrecall-arm
cmake -S . -B build -DCMAKE_BUILD_TYPE=Release -DBUILD_TESTING=ON
cmake --build build --parallel
ctest --test-dir build --output-on-failure
python3 -B -m unittest discover -s scripts/tests -v
./build/neonrecall selftest --json
./build/neonrecall search-demo

The repository documents the longer native evidence route, including the pinned model assets, three benchmark repetitions, raw retrieval results, ELF checks, disassembly, and aggregation gates.

Where this technique fits

This design is relevant when retrieval arithmetic is a meaningful part of a CPU-bound RAG, recommendation, or vector-search workload and the embeddings already exist.

It does not answer whether end-to-end application latency will improve by the same factor. That depends on model inference, data movement, index structure, concurrency, filtering, and the surrounding service. A useful next step would be testing larger corpora and a production index while measuring end-to-end latency and resident memory separately.

For this experiment, the narrower result is the useful one: replacing FP32 search arithmetic with a purpose-built INT8 representation and an Arm NEON dot-product path produced a substantial, reproducible speedup on native Arm64.

Project links

NeonRecall is Apache-2.0 licensed and was built for Track 2: Cloud AI in the Arm Create: AI Optimization Challenge.

I ported Picomatch to Rust. It passed 1,977 tests and lost the benchmark by 18x

LubuSeb — Sun, 02 Aug 2026 14:09:38 +0000

A Port Mortem 2026 write-up about a JavaScript to Rust port, one strange Unicode character, and what green tests do not tell you.

The first benchmark result was not flattering.

Picomatch, running under Node, handled about 7.18 million matches per second in my test. The direct Rust implementation managed about 395,000. That made the Rust version roughly 18.2 times slower.

I kept the result because it makes the point of the project clearer. The hard part was verification: how much evidence would it take to trust an AI-assisted rewrite beyond the obvious cases?

The small library that was not a small target

Picomatch is a dependency-free glob matcher used across the JavaScript ecosystem. Its committed runtime is only 2,444 lines of JavaScript, which made it look like a sensible target for a 72-hour port.

The scope was reasonable for 72 hours, but I underestimated the compatibility surface.

Matching *.js is easy. Matching Picomatch means dealing with globstars at path boundaries, nested extglobs, braces, negation, captures, callbacks, Bash and minimatch options, Windows separators, JavaScript regex flags, UTF-16 indexes, and inputs designed to make a parser or regex engine suffer.

I chose the official Picomatch snapshot at commit 4f41a8e and wrote a standalone Rust scanner, compiler, and matcher. The command-line program runs without Node. A small JavaScript adapter exists for the unchanged upstream test suite because those tests expect JavaScript callbacks, RegExp objects, and synchronous API behavior. It does not contain a fallback glob matcher. Every search that is not an API shortcut runs in Rust.

Getting that boundary right mattered. Otherwise I could have produced a convincing test report while quietly letting JavaScript do the difficult work.

All 1,977 tests were green. The port was still wrong

The inherited Picomatch suite eventually passed in full. All 1,977 tests were green, and the repository also had 28 native Rust tests.

Then differential testing found more problems.

One of the clearest mismatches involved ſ, the Latin long s. It looks a little like an f without the full crossbar. JavaScript treats it differently depending on whether a regular expression uses legacy case-insensitive matching or Unicode-aware case-insensitive matching:

/s/i.test('ſ')   // false
/s/iu.test('ſ')  // true

/k/i.test('K')   // false
/k/iu.test('K')  // true

My early implementation treated case-insensitive matching as one Unicode problem. JavaScript actually has two relevant behaviors here. Legacy /i uses its own Canonicalize rules. Adding u changes the result for characters such as long s and the Kelvin sign.

An engine can call itself ECMAScript-compatible and still miss exactly this sort of historical corner.

Instead of adding only those two characters as regressions, I pinned Node 24.18.0, derived the complete legacy Canonicalize table for the Basic Multilingual Plane, and added it to the native engine. The proof walks all 65,536 BMP code units, finds every nonidentity mapping, and checks both literal and character-class matching against Node and the pinned Picomatch version.

That produced 1,169 nonidentity mappings, 2,392 ordered equivalences, and 4,784 literal and class checks. The odd character that exposed the bug became a test for the whole defined scope.

The upstream suite was useful, but I did not want the final claim to depend on one set of examples or on hashes created inside my own repository.

The proof grew in layers:

Evidence	Result
Upstream provenance	38 test and fixture files pinned to Picomatch commit `4f41a8e`, fetched and byte-compared
Original suite	1,977 unchanged tests passed
Native regressions	28 Rust tests passed
Generated differential cases	100,000 comparisons across five fixed seeds
Directed differential cases	535 executions, replaying 107 known edge cases under every seed
Legacy case folding	4,784 literal and class checks over the derived BMP mappings

The provenance check deserves a little explanation. A local checksum only proves that files did not change after I hashed them. It does not prove that I started with the upstream files. The stronger check fetches the exact upstream commit, confirms that the manifest covers the complete test tree, normalizes line endings, and byte-compares every file.

The differential harness runs the pinned JavaScript implementation and the Rust port on the same generated patterns, paths, platform modes, and options. It includes extglobs, braces, classes, negation, Unicode, separators, and captures. Five fixed seeds keep it reproducible. Known failures are kept as directed cases instead of being left to chance.

The final run reported zero mismatches across 100,535 differential executions.

That is not a formal proof over every possible string. It is bounded, reproducible evidence. I think saying where the evidence stops is part of making it useful.

Extglobs needed a compiler, not substitutions

Another early mistake was thinking too locally about extglobs. Operators such as ?(), *(), +(), @(), and !() look like five pieces of syntax that can be translated one at a time.

They cannot. Nesting changes the meaning. So do suffixes, alternation, path separators, captures, and repetition. A shallow implementation handled ordinary examples, then stalled or under-matched cases with nested negative extglobs.

The correction was structural. The compiler now reduces pure chains of nested negation by parity while preserving the surrounding suffix and alternative context. It rewrites only repeated languages that it can show are safe, and it keeps the ambiguous cases literal when that is what Picomatch requires.

Earlier adversarial and differential runs were more useful than the final zero-mismatch total because they supplied the cases that became permanent regressions. Those cases include nested negation, legacy case folding, capture numbering, regex flags, typed transport fields, Windows separators, globstar boundaries, and eager ignore behavior.

A second compiler problem came from Picomatch's public regex source. APIs such as parse and makeRe expose the generated regular expression, and some upstream tests inspect it. At the same time, the Rust matcher needs an execution form that makes path-separator rules explicit.

I initially tried to make one generated regex serve both purposes. That forced a bad choice. I could satisfy observable source assertions, or I could enforce native path behavior, but not always both with the same representation.

The final compiler emits two related forms. One is the public source used by the compatibility API. The other is a private, slash-safe execution source used by Rust. Both come from the same compiler, but they have different jobs.

Captures made the same lesson harder to ignore. With capture: true, compiler-generated groups affect backreference numbering. Wildcards, braces, brackets, extglobs, named groups, and unmatched groups all need to be planned while the regex is emitted. Rust now returns the full match and every capture as UTF-16 spans. The adapter uses those spans to reconstruct the JavaScript result, including named groups and d-flag indices. JavaScript owns state such as g and y lastIndex, but Rust performs each search from the requested position.

A safety limit must not look like a non-match

Glob patterns eventually become regular expressions, and regular expressions can backtrack badly. Limiting the parser was not enough. A valid-looking pattern could still consume unreasonable execution work.

The compiler now bounds pattern length, nesting depth, branch count, unmatched bracket markers, and total compile work. The vendored regex engine also has deterministic execution fuel. Dispatch, scans, backtracking, and backreference comparisons all spend from the same budget.

When that budget runs out, the matcher returns a recoverable safe work limit error. It does not return false.

That distinction matters. A non-match says the engine finished and found no match. Exhaustion says the engine could not safely finish. Treating those as the same result could select or skip the wrong files in a build pipeline.

The safety tests include both sides. A linear match against a one-million-character input succeeds. The hostile pattern +(a*)b against a short near-miss reaches the work limit and returns an explicit error. The next ordinary request still succeeds through the same persistent process.

What the benchmark measured

I benchmarked three paths using the same four precompiled pattern and input pairs. Each path returned the same 75 percent match rate. The figures below are medians from three timed runs after warm-up.

Path	Median throughput
Picomatch on Node	7,184,496 ops/s
Direct native Rust API	395,048 ops/s
Rust through the synchronous proof adapter	11,602 ops/s

V8's optimized regular-expression engine is extremely fast. The Rust implementation uses a safe ECMAScript interpreter with explicit fuel accounting. The proof adapter adds worker wakeups, framing, IPC, cache lookup, and JavaScript object reconstruction on top of that.

If throughput were the only goal, this port would lose. The direct native matcher is still practical at roughly 0.40 million matches per second for this workload, but I am not presenting it as a speed improvement.

So the port's value is not higher throughput. The Rust API and CLI run independently of Node, expensive work fails explicitly, and the repository provides a reproducible compatibility check. Publishing only the flattering measurements would weaken that claim.

What I would do differently

If I started again, I would build a small JavaScript regex conformance probe before committing to the first execution-engine design.

It would cover legacy /i versus /iu, UTF-16 offsets, named and unmatched captures, d indices, g and y state, lookarounds, and backreferences. I would also separate the public regex source from the private execution form on day one.

Instead, those facts arrived as failures during integration. The failures led to a better design, but they cost time late in the build when every change touched the compiler, matcher, adapter, and proof harness.

I would also add direct upstream byte comparison earlier. Repository-owned hashes felt reassuring until an independent review pointed out that the repository was effectively certifying itself.

That review process was deliberate. I used separate coding agents to challenge the Rust design, provenance, fuzz grammar, captures, flags, safety, benchmarks, and presentation. I only accepted a concern when I could reproduce it as a failing case and run the fix through the full suite.

What I would reuse on the next port

The process that held up was fairly simple:

Pin the exact source revision and fetch it during verification.
Keep the inherited tests unchanged.
Run the source and target implementations on the same generated inputs.
Turn every mismatch into a permanent directed regression.
Exhaustively test small domains that are defined by a specification.
Benchmark the unflattering paths too.
State the implementation boundary and the limits of the proof.

Picomatch Mortis now passes all 1,977 frozen upstream tests and 28 native tests. Its current bounded differential corpus reports zero mismatches across 100,535 executions. Rust owns scanning, compilation, and every non-short-circuited match, capture, and ignore search. JavaScript remains at the API boundary where JavaScript objects and callbacks require it.

Receipts

Built for Hackathon Raptors, @raptors_hack, and the Port Mortem 2026 JavaScript to Rust track.