I spent one day smashing three real open source bugs

I spent one day smashing three real open source bugs

Tópico: I spent one day smashing three real open source bugs
Categoria: Tutoriais | Programação & Tecnologia
Idioma Principal: Português (Conteúdo de Tecnologia)

Descrição do Conteúdo / Informações:
-------------------------------------------------------------------------
This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

When the Summer Bug Smash challenge started, I gave myself one rule. Every fix has to be real, and every fix has to carry its own test that fails before the change and passes after it. I gave myself one day to see how far that rule could take me. It took me through three open source projects, three pull requests, and a lot of green check marks. Here is how it went, bug by bug.

Bug one: a gateway that kept restarting itself

My first stop was OpenClaw, a personal AI assistant project written in TypeScript. Issue 119360 described something spooky. When you changed a setting in the UI and then pressed cancel, the gateway still restarted. Cancel was supposed to mean do nothing, yet the process bounced anyway, dropping every active session on the floor.

Reading the code made the ghost visible. The restart planner compared your current config against a baseline it called the runtime compare config. That baseline was supposed to represent what the gateway was actually running. But it got updated during planning, before any reload was accepted. So when you cancelled, the planner compared your config against a baseline that had already drifted toward it, saw a mismatch, and ordered a restart for changes you had just taken back.

The fix keeps planning pinned to the config the user actually accepted, and lets the runtime baseline move only when a reload truly goes through. On top of that I added a narrow gate so a plain revert cancels cleanly instead of scheduling a pointless bounce. The hard part was scope. A careless gate here can swallow real restarts, like plugin or MCP runtime changes, which must always trigger one. The final condition only fires when there are config level diffs, no plugin reload is planned, no MCP disposal is planned, and the runtime diff is empty.

fix(gateway): cancel deferred restart when config settles back to the runtime baseline

#128127

aniruddhaadak80
posted on Aug 23, 2026

Fixes #119360

What Problem This Solves

A transient write to a restart-required config path (e.g. gateway.tools.allow) followed by a same-session revert that leaves openclaw.json byte-identical to the pre-change file still schedules and performs a full Gateway restart (SIGUSR1 after drain). Restart debt latches onto the first restart-required candidate and survives superseding writes, so operators who probe a setting and immediately undo it still lose Control UI / channel sessions for a full restart cycle.

Root cause

The reloader plans every candidate against a single acceptance baseline (currentCompareConfig). Once restart-required candidate B is observed and accepted, that baseline becomes B — so when the file later settles back to the original running bytes A, the planner diffs A against B, still sees protected-path changes, and re-arms the deferred restart even though nothing differs from what the process is actually running.

Fix

Planning continues to use the acceptance baseline untouched (hot/no-op classification, runtime-overlay handling, and managed-restart choreography depend on it). The change adds a separate runtime reference — what this process has actually adopted — and uses it for exactly one decision:

•
currentRuntimeCompareConfig advances whenever the process adopts a snapshot (markRuntimeCommitted, normal commitReloadBaseline completion) but deliberately not for restart-deferred candidates or runtime-skipped ones.

• In both restart branches (followUp.requiresRestart and plan.restartGateway), before arming via prepareRestart, an exact revert check runs: if the candidate deep-equals currentRuntimeCompareConfig, the deferred restart is cancelled (logged, committed as baseline, no SIGUSR1).

This keeps every existing planning behaviour intact — candidates on top of a deferred config still hot-reload against the deferred baseline and still revalidate pending restart secrets — while an exact revert-to-running can no longer re-arm debt. Plugin reload/MCP-dispose plans are exempt from the cancel so bundled-plugin work is never dropped by the shortcut.

Evidence

New regression test in src/gateway/config-reload.test.ts — "does not re-request a restart when a deferred config reverts to the runtime baseline":

• Runtime starts on baseline config A.

• Watcher observes restart-required config B → onRestart fires once.

• Watcher observes bytes identical to A again.

• Asserts onRestart is still exactly once, with no onHotReload and no onNoopConfigCommit — the revert is absorbed without arming anything.

Matching handler-surface coverage added in src/gateway/server-reload-handlers.test.ts ("cancels a deferred restart when config returns to the running baseline").

Verification trail during development:

• First revision diffed planning directly against the runtime baseline; upstream CI's plans one immutable runtime override snapshot per candidate caught that this starves no-op classification of runtime-overlay reversals (reproduced locally pre/post-fix), and the Gmail handler suite showed hot-reload sequences must keep planning against the acceptance baseline. The design was corrected accordingly: acceptance baseline drives planning; the runtime baseline only gates the restart-arm decision.

• Local Windows sandbox cannot run the chokidar-flush tests reliably (symlink EPERM + FSWatcher latency; identical failures with and without the patch, confirmed via A/B filtered runs), so Linux CI is the authoritative validation for this suite.

View on GitHub

The full CI matrix ended at 206 checks, all green, including two large test shards that stress exactly this path.

Bug two: a slider that forgot which way to read

Second stop, Rocket.Chat's design system, Fuselage. Two related bugs lived in the Slider component's track fill. First, the colored fill between thumb and track start used left to right math only, so in right to left locales like Arabic or Hebrew the fill sat on the wrong side of the thumb. Second, if a slider had a minValue above zero, the fill ignored it and drew from the very start of the track, showing a range that did not match reality.

Both problems shared one root cause. The fill computed percentages by hand instead of asking the component state. My change makes it read the thumb percent straight from state, then flips the gradient direction based on locale direction. Writing the tests first paid off here. Three of them failed against the old code, and all eight passed after the fix.

fix(fuselage): correct Slider track fill for non-zero minValue and RTL locales

#2169

aniruddhaadak80
posted on Aug 23, 2026

Original commits

Fixes the Slider track fill rendering in two scenarios where it did not match the actual thumb position:

1. Non-zero minValue produced a wrong fill position

getThumbPosition computed (value / (maxValue - minValue)) * 100, which ignores the offset of minValue. For example, a slider with minValue={50} maxValue={150} and value 100 rendered its fill at 100% instead of 50%.

The component now uses react-stately's own percent calculation (state.getThumbPercent(index)), which also fixes multi-thumb sliders where each thumb can have a different range (previously both thumbs shared getThumbMaxValue(1) || getThumbMaxValue(0)).

2. Horizontal fill ignored RTL direction

react-aria flips horizontal slider geometry in RTL locales, but the track gradient was hardcoded to to right, so in RTL languages the filled portion appeared on the wrong side of the thumb. The gradient direction now follows useLocale().direction.

Evidence that the new tests catch the original bugs

Running the updated spec against the old SliderTrack.tsx:

x should position the track fill relative to minValue
x should mirror the track fill direction in RTL locales
x should keep the multi-thumb band ordered in RTL locales
Tests: 3 failed, 5 passed, 8 total

With the fixed SliderTrack.tsx:

PASS packages/fuselage/src/components/Slider/Slider.spec.tsx
Tests: 8 passed, 8 total

The vertical slider path is intentionally untouched: to top + percent-from-min was already correct for vertical orientation.

@rocket.chat/fuselage patch changeset included.

View on GitHub

A changeset is included so the library gets a proper version bump when the maintainers merge.

Bug three: unknown[unknown] everywhere

Third stop, npmx.dev, a package registry that renders API docs for npm packages. Its documentation engine formats types coming out of deno doc JSON. Issue 3154 reported that many modern TypeScript types rendered as unknown[unknown]. Intersections, tuples, conditional types, mapped types, imported types, type predicates, typeof queries, infer positions, rest and optional members, even parenthesized groups all fell into a default branch that printed that sad pair of words.

I added eleven small formatters, one per kind, plus proper handling for bigInt literals and template literals while I was in there. Each formatter follows the existing style in the file, and the shared type definitions were extended to match what deno doc can actually emit. Eight regression tests now cover the exact shapes from the issue, and the whole unit suite for the formatter module passes.

fix(docs): format complex tsType kinds instead of rendering unknown

#3200

aniruddhaadak80
posted on Aug 23, 2026

Resolves: #3154

Problem

On package docs pages, exported symbols whose types are built from intersection / conditional / mapped / tuple constructs rendered as the literal string unknown — e.g. https://npmx.dev/package-docs/trslate/v/1.6.4 showed:

constructor(schema: T, arg_1: unknown)
type SKey<T> = unknown[unknown]

even though the package's index.d.ts contains proper types.

Root cause

formatType() in server/utils/docs/format.ts implemented recursive formatters for only 10 of the ~21 TsType kinds that @deno/[email protected] emits. Unhandled kinds fell back to type.repr, but deno_doc returns an empty string for repr on structured types (intersections, mapped/conditional types, type literals — visible in our own fixtures), so the final fallback produced unknown.

This is the same failure mode previously fixed for #1411 by adding formatters (fnOrConstructor, typeLiteral, indexedAccess, typeOperator) — this PR extends the same pattern to the remaining kinds.

Fix

• Added formatters for: intersection, tuple, parenthesized, rest, optional, typeQuery, conditional, mapped, importType, infer, typePredicate.

• Extended the literal formatter to handle bigInt and template literals.

• Arrays now parenthesize union/intersection/conditional/function-typed element types ((A | B)[] instead of invalid A | B[]); intersections parenthesize union/conditional/function members.

• Extended the hand-rolled TsType interface in shared/types/deno-doc.ts with the missing fields, matching the flat serde shape of @deno/doc 0.189.1 (js/types.d.ts).

With the fix, the trslate signatures render as:

constructor(schema: T, args: K & T[length]): Translation<T>

Tests

Added a regression suite in test/unit/server/utils/docs/format.spec.ts mirroring trslate's real d.ts shapes:

Test Files 1 passed (1)
Tests 14 passed (14)

(8 new tests covering intersections, conditionals, mapped types, indexed access over mapped/intersection members, tuples + rest, typeof queries, import types, infer, type predicates, bigInt/template literals, and an end-to-end function signature.)

View on GitHub

What the day taught me

Three things stuck with me. First, a tiny reproduction is worth an hour of staring. Every one of these bugs became obvious the moment I could trigger it on demand. Second, tests that fail first are the cheapest proof that a fix does something. They also protect the next person who touches the code. Third, reading the surrounding code before writing anything saves more time than it costs. Every repo already had conventions for tests, changesets, and commit style, and following them made review easy for everyone.

Wrap up

Three projects, three fixes, each shipped with failing first tests and green CI. The challenge closes on August 24, so if you have been waiting for a reason to send your first bug fix, this is a good one. Pick an issue that annoys you, shrink it until it fits on one screen, and make the test prove you killed it.