DEV Community: Pentine Pejay

An 80-second browser freeze in Zulip's Manage channels, fixed by killing quadratic DOM work

Pentine Pejay — Fri, 21 Aug 2026 19:06:01 +0000

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

Project Overview

Zulip is an open-source team chat application: a Django backend and a TypeScript web client built on jQuery. The "Manage channels" overlay lists every channel you can see, with live search, sort, and filter. Each keystroke or filter change re-sorts the list in place.

Bug Fix or Performance Improvement

I fixed issue #39755. On a server with about 331 channels, opening Manage channels (or the #channels/new view, or the All tab) makes the tab unresponsive for roughly 80 seconds. Chrome shows the "Page Unresponsive" dialog. The reporter's Chrome CPU profile pinned about 90% of the freeze on two DOM operations, removeChild and querySelectorAll, triggered through the bundled jQuery.

The code is redraw_left_panel() in web/src/stream_settings_ui.ts, which sorts the list by moving DOM rows into their new order. The re-append loop looked like this:

for (const stream_id of all_stream_ids) {
    const $widget = widgets.get(stream_id);
    scroll_util
        .get_content_element($("#channels_overlay_container .streams-list")) // re-queried every iteration
        .append($widget);
}

The problem is the $("#channels_overlay_container .streams-list") inside the loop. That is a document-wide querySelectorAll, run once per channel. A querySelectorAll forces the browser to flush pending layout, so every one of the N appends triggers a full re-layout of the list. Detaching and re-appending N rows with a forced reflow each time is O(n²). With a few hundred rows, that is the 80-second freeze, and it matches the profile exactly: removeChild from the per-row detach, querySelectorAll from the per-row re-query.

Code

PR: https://github.com/kiprutopentine/zulip/pull/1

The fix, in redraw_left_panel():

// Query the content element once, before the loop.
const $content_element = scroll_util.get_content_element(
    $("#channels_overlay_container .streams-list"),
);

// ...scan .stream-row a single time, set classes, detach rows...

// Re-append each row into the CACHED element. The original re-queried the
// content element here on every iteration; that document-wide querySelectorAll
// forces a synchronous layout flush of the pending append, so each row paid a
// full reflow. Caching it removes the forced layout, and one append form keeps
// the change lint- and mock-compatible with the existing test.
for (const stream_id of all_stream_ids) {
    const $widget = widgets.get(stream_id);
    assert($widget !== undefined);
    $content_element.append($widget);
}

Three changes: query the content element once (this removes the per-row querySelectorAll and the forced synchronous layout it caused), scan .stream-row a single time instead of twice, and re-append each row into that cached element instead of re-looking it up every iteration. The ordering, the notdisplayed classes, and the function's return value are all unchanged, so behavior is identical, only the DOM work drops from O(n²) to O(n).

My Improvements

I kept the change inside the existing function and its jQuery idiom rather than rewriting the overlay. That was deliberate: Zulip's frontend tests run against a jQuery mock (zjquery) whose elements are not real DOM nodes, so a raw DocumentFragment reorder would pass in the browser but break the test suite. Staying on .detach() / .append() keeps the existing redraw_left_panel test valid, which already asserts the sorted order across search, sort, and filter cases.

Removed the per-iteration content-element lookup, the O(n²) driver: a document-wide querySelectorAll that forced a synchronous layout flush of the pending append on every row.
Collapsed two .stream-row scans into one.
Kept the plain .append($row) form, so the change is behavior- and lint-identical to the original and compatible with Zulip's zjquery test mock (a raw DocumentFragment reorder would pass in a browser but break the mock, whose elements are not real DOM nodes).

Verification: I provisioned a full Zulip dev environment on a throwaway cloud VM and ran Zulip's own tooling against the fix:

./tools/test-js-with-node stream_settings_ui → test: redraw_left_panel passes ("Test(s) passed. SUCCESS!").
./tools/run-tsc clean.
./tools/lint --only=eslint,prettier web/src/stream_settings_ui.ts clean.

The change is behavior-preserving (same order, notdisplayed classes, return value), so that existing test, which pins ordering across search, sort, and filter cases, passes unchanged.

Best Use of Sentry

This is a performance bug with zero exceptions, so error monitoring alone would never see it. I used Sentry's performance tooling to make the cost visible and to prove the fix.

I built a benchmark harness (@sentry/browser via the loader script) that rebuilds the exact redraw both ways against N real .stream-row nodes and wraps each run in a Sentry span named manage_channels.redraw_left_panel (op: ui.render):

OLD detaches each row and re-appends one at a time, re-querying the content element every iteration (forcing a synchronous layout per row): O(n²).
NEW queries the content element once and re-inserts in a single batch: O(n).

Measured in the harness, which is deliberately minimal (plain rows) so the numbers isolate the algorithm itself rather than Zulip's full per-row render cost:

channels	OLD (buggy)	NEW (fixed)
331	115.8 ms	3.7 ms
1000	477.4 ms	7.3 ms
2000	2340.4 ms	15.1 ms

OLD grows super-linearly, close to quadratic at the larger sizes: doubling the list from 1000 to 2000 channels roughly quintuples the time. NEW scales linearly and stays in the low milliseconds. At 2000 channels the redraw drops from 2.3 seconds to 15 ms, about 155x. In the production overlay each row is far heavier (real templates, jQuery, the scroll container), so the same pattern is what turns "a few hundred channels" into the reporter's ~80-second freeze instead of a fraction of a second. The harness proves the mechanism and the fix; the 80 seconds is the real-world symptom of it.

Performance / tracing: the OLD run does not just take longer, it blocks the browser's main thread. Sentry's tracing recorded it as a ui.long-animation-frame — Main UI thread blocked span (about 1.3 s in this trace), exactly the kind of long task that makes the tab unresponsive. The NEW run produces no such block.

Each run is tagged with its channels count and its kind (old/new), so the regression is visible inside Sentry, not just in the console. Filtering the manage_channels.redraw_left_panel transactions shows the fixed runs sitting in the low milliseconds (4–30 ms) while the buggy runs climb with the channel count, from ~100 ms up past 2 seconds, and beyond 17 seconds on a larger list. Sentry is not just recording one slow event; it shows the shape of the algorithm, and that the fix flattens it.

Session Replay: the replay of the OLD run shows the list locked and unresponsive; the NEW run is instant.

Three Sentry surfaces carried this fix: tracing timed each redraw as a ui.render transaction and plotted the cost curve as the channel count grew, its long-animation-frame detection flagged the blocked main thread on its own, and Session Replay captured the freeze the way a user feels it. Run it yourself, the harness is public at https://github.com/kiprutopentine/sentry

Dog Passport: a soulbound vaccination record your vet signs, on Solana

Pentine Pejay — Sun, 16 Aug 2026 19:45:59 +0000

This is a submission for Weekend Challenge: Dog Days Edition

What I Built

Dog Passport turns a dog's vaccination and pedigree record into a
non-transferable Token-2022 on Solana that the issuing vet signs with their own
keypair.

A boarding kennel, groomer, border agent, or a new owner can open the passport,read it straight from the chain, and see two things at once: the dog's details,and whether the record was really signed by a known vet. No app account, no central server to trust, no company that can shut down and take the records with it. The token is soulbound, so it stays bound to the dog and cannot be sold or swapped like an NFT.

The problem is small and real. Paper vaccination cards get lost right when you need them for boarding or travel. Pet-record apps die with the company that made them. Breeders hand over pedigrees you have no way to check. A vet-signed on-chain record fixes the parts that hurt: it is portable, tamper-evident, and outlives any single vendor.

The passport carries a photo, passport number, owner, breed, date of birth, colour, microchip, the vaccination history, and the issuing vet's key. Every one of those fields, including the photo, is covered by the vet's signature.

Demo

Live (Solana devnet, no wallet or setup needed):

App: https://bosco-eta.vercel.app

bosco-eta.vercel.app

Open a passport directly: https://bosco-eta.vercel.app/?mint=52SP5ACC7m8BwnWge1CX3DyidhfBXWLxAz9yNdS2sf3G

The landing page has a gallery of five real dogs plus two test states, so you can click through every verification outcome:

Authentic — signed by a trusted vet. Green "VERIFIED" stamp, all checks pass.
Untrusted issuer — a valid signature from a vet who is not in the trusted list. Amber stamp.
Tampered — a field was altered on-chain after signing, so the signature nolonger matches. Red "INVALID" stamp.

The viewer renders a proper passport data page: photo, fields, a machine-readable zone, per-vaccine validity status (up to date, due soon, overdue), a verification checklist, and a QR code of the shareable link. It can also scan a printed passport QR with the device camera.

Open the live link above and click the gallery chips to see each outcome for yourself, straight from devnet.

The verification is honest. Change any field in the record and the signature no longer matches:

original verifies  : true
tampered breed     : false
tampered vaccine   : false
wrong issuer key   : false

Code

kiprutopentine / dog-passport

Dog Passport

A dog's vaccination and pedigree record issued as a non-transferable Token-2022 on Solana. A vet signs each record with their keypair, so a boarding kennel groomer, border agent, or new owner can verify the record is authentic and came from a specific vet, without trusting any central server or app.

Runs on Solana devnet.

Why on-chain

Paper vaccination records get lost. App-based pet records die when the app or company shuts down. A breeder can hand you a pedigree with no way to check it. Putting the record on-chain as a soulbound token makes it portable, tamper-evident, and independent of any single vendor. The passport is bound to the dog, not tradeable, so it cannot be sold or swapped like an NFT.

How it works

Each passport is one Token-2022 mint with three extensions:

NonTransferable — the token is soulbound. Once minted to the owner it cannot be…

View on GitHub

How I Built It

Stack: plain @solana/web3.js + @solana/spl-token, no Anchor program. A handful of Node scripts plus a static viewer, small enough to build and verify in a weekend.

The Solana part that matters. Each passport is one Token-2022 mint that combines three SPL Token Extensions:

NonTransferable makes the token soulbound. I de-risked this first with a proof-of-concept that mints a token and then tries to transfer it. The program rejects the transfer, which is exactly what a passport needs.
MetadataPointer points the mint at itself for metadata, so there is no separate metadata account.
TokenMetadata stores the whole record on-chain in additionalMetadata:passport number, name, breed, dob, sex, colour, microchip, owner, photo URL andits SHA-256 hash, the vaccine list, the issuing authority, the vet's public key, and the vet's signature.

Issuer-signed records. The value is not "data on a chain," it is who signed it. The vet holds an Ed25519 keypair. Before minting, the vet signs a canonical serialization of the record (stable key order, reproducible byte-for-byte) with tweetnacl. That detached signature goes on-chain. Verification recomputes the canonical record from the on-chain fields, checks the signature against the vet's
public key, then checks that key against a trusted-vet list. Tampering fails because the bytes being verified no longer match the bytes that were signed.

Photo integrity. The image is bound to the record by hashing its bytes and signing the hash. The viewer re-hashes the photo it displays and compares, so the picture cannot be swapped without breaking verification.

The viewer and hosting. The on-chain read and the verification run in one loadAndVerifyPassport function shared by the CLI and the web. On Vercel it runs as a serverless function at /api/passport; locally the same function runs behind a small Node server. The function is host-agnostic: it reads the photo and the trusted-vet list over HTTP from its own deployment, so nothing from the local
filesystem has to be bundled.

Two things that fought back. The public devnet faucet was rate-limited to death, so funding falls back across endpoints (an Alchemy demo endpoint saved the day). And on Vercel, @solana/web3.js pulls in rpc-websockets, which bundles an ESM-only uuid and then require()s it, crashing the function with ERR_REQUIRE_ESM; pinning uuid to its CommonJS build via an npm overrides fixed it.

Prize Categories

Best Use of Solana. - Used Token-2022's NonTransferable extension to make the passport soulbound, on-chain TokenMetadata to carry the record, and the issuer-signature model to make verification about the vet rather than a server.

What's next

Real vet identity: a registry or attestations instead of a local trusted list.
An owner-transfer flow for rehoming and adoption, without making the token freely tradeable.
Mainnet custody and a kennel/border scanner app.