DEV Community: Wajdy Mustafa

I tested my own Chrome extension with Playwright and found 3 bugs, including one that silently killed the entire UI.

Wajdy Mustafa — Thu, 03 Sep 2026 16:54:19 +0000

I built a Chrome extension that replaces the new tab page with a daily sudoku puzzle. The generator and verifier were solid -- I'd already independently confirmed every puzzle has exactly one solution. What I hadn't done yet was actually test the extension itself. That gap mattered.

Actually launching a browser beats reading the code again

I used Playwright to load the extension's new-tab page for real, in a real Chromium instance, and drove it the way a person would: click a cell, type a number, click Reveal, click Check. First run: blank page. No board, no numbers, nothing. Reading the code wouldn't have caught this nearly as fast -- the bug only shows up outside the extension's own execution context.

The three bugs

The blank page came from if (chrome && chrome.storage...). Referencing an undefined global directly throws a ReferenceError -- it needs typeof chrome !== "undefined" first. Outside the extension's own context, that one line crashed the entire script silently, before the board ever rendered.
A footer link read "More puzzles \u2192" -- literally, backslash-u-2192, not an arrow. HTML doesn't interpret JS-style unicode escapes in plain text; that syntax only works inside a JS string. Needed the actual character or an HTML entity.
That same footer link pointed at one specific book's ASIN, even though the extension rotates through three difficulty levels tied to three different books. Fixed by linking to a series search instead of a single title.

What actually got covered

After the fixes: cell input, wrong-answer detection (filled every empty cell with the same digit, confirmed the right ones got flagged red), reveal-then-check, difficulty switching, and localStorage persistence across a page reload. All driven the same way -- click, type, screenshot, verify -- not asserted from reading the source.

It's live on the Chrome Web Store now -- free, no tracking, puzzles bundled and verified offline. Link in the comments.

Notion's paid "Automations" feature isn't required for spaced repetition. Here's the free-plan version.

Wajdy Mustafa — Thu, 03 Sep 2026 03:22:33 +0000

I built a spaced repetition flashcard template in Notion using the actual SM-2 algorithm (the one behind Anki), not a simplified guess. Along the way I hit a real platform constraint worth knowing about if you're building anything similar.

The algorithm, actually implemented correctly

SM-2 tracks three numbers per card: an ease factor (starts at 2.5), an interval, and a repetition count. Rate your recall 0-5 after each review, and the algorithm decides how many days until you see that card again -- longer each time you get it right, reset to 1 day the moment you forget it. I cross-checked the exact 1987 Wozniak formula against a working implementation before writing a single formula, rather than reconstructing it from memory.

The wall: Notion's Automations are a paid feature

The obvious design: a database automation that updates ease factor, interval, and repetitions the instant you rate a card. Clean, one-click, no manual math. Except Notion's "when property changes, edit another property" automations sit behind a plan upgrade -- I only found out by actually opening the automations panel, not by reading pricing docs in advance.

The free-plan workaround

Formula properties don't need Automations -- they just compute and display a value from other properties, live, on any plan. So instead of auto-updating the real fields, I added three formula columns -- Suggested Ease Factor, Suggested Interval, Suggested Repetitions -- that calculate the correct next values the moment you set a rating. You copy those three numbers into the real fields yourself. Two extra clicks per review, zero dollars a month, same correct math.

Checked, not assumed

I hand-calculated two scenarios before trusting the formulas: a perfect recall (ease factor 2.5 -> 2.6, interval -> 1 day) and a total failure (ease factor 2.5 -> 1.7, interval and repetitions both reset). Notion's live formula preview matched both by hand, exactly. Small thing, but it's the difference between a template that looks right and one that actually is.

I verified a spreadsheet's formulas against a from-scratch simulation. Found 3 bugs before anyone else could.

Wajdy Mustafa — Tue, 01 Sep 2026 17:46:59 +0000

I built a personal finance spreadsheet with a debt payoff cascade: up to 5 debts, a custom priority order, and 60 months of month-by-month projection. The interesting part wasn't the UI, it was proving the math was actually right.

The problem with "the formulas evaluate cleanly"

A recalc pass telling you a spreadsheet has zero formula errors proves the formulas ran. It doesn't prove they computed the right numbers. That gap matters most exactly where the logic is hardest: a debt payoff planner where extra payments cascade from one debt to the next as each gets paid off, in whatever priority order the user picks.

So I wrote a second, completely independent implementation in Python -- a plain month-by-month simulation with no spreadsheet functions at all -- and diffed every cell against it.

What that caught

Three real bugs, none of which a clean recalc would ever surface:

An off-by-one in a summary formula's range that silently pulled from the wrong row
A print area that excluded the entire 60-row schedule table -- looked fine on screen, would have printed blank
Column widths that truncated labels so "Annual Interest Rate" read as "Annual Inter"

None of these are exotic. That's the point -- they're exactly the kind of thing that hides behind "0 errors" in a recalc log, and exactly the kind of thing a from-scratch independent check is designed to catch. The final cascade -- 5 debts, 60 months, 1,200 data points -- matched the reference simulation to within 5e-12.

Packaged the result as a small finance toolkit (budget tracker, this debt payoff planner, a loan amortization calculator, a savings compound-growth projector) -- link in the comments if anyone wants to see the actual sheet.

52% of tested MCP server endpoints were completely dead

Wajdy Mustafa — Sat, 29 Aug 2026 22:09:39 +0000

Originally published at n8nkit.com.

A 2026 analysis of over 2,100 remote MCP server endpoints found that more than half were completely dead. Not erroring. Not timing out with a clear signal. Just not working ΓÇö while still accepting a connection.

That statistic points at a category error most health checks make: treating "connected" and "working" as the same fact.

Why this failure mode is easy to miss

Most monitoring instinct comes from web services, where "connected" and "working" are close enough that conflating them rarely costs you. MCP breaks that assumption.

The protocol layer (does the connection open) and the application layer (does a real tool call return a correct result) are genuinely separate questions. A server can complete a handshake, report itself as reachable, and still fail every actual tool call it receives. A connection-only check sees a green light. A user sees nothing happen.

There's a second, quieter problem in the same neighborhood: MCP stdio servers communicate over stdout. A single stray print() or console.log() ΓÇö the most natural debugging instinct there is ΓÇö writes directly into the protocol stream and corrupts every message that follows it.

This is a documented, common mistake rather than an edge case, precisely because logging to stdout is the default reflex for most developers.

What a real health check has to do

The fix isn't more monitoring. It's monitoring the right thing.

A health check that actually catches this has to make a round-trip tool call and verify the response, separately from checking that the connection opened:

def check_server_health(name, connect_fn, probe_fn, timeout_seconds=10.0):
    start = time.monotonic()
    try:
        connection = connect_fn()
    except Exception as e:
        return Result(name, healthy=False, error=f"connect failed: {e}")

    try:
        probe_fn(connection)   # a real tool call, not a ping
    except Exception as e:
        return Result(name, healthy=False, error=f"probe failed: {e}")

    return Result(name, healthy=True,
                  latency_ms=(time.monotonic() - start) * 1000)

The distinction between connect failed and probe failed is the entire point. A server that connects but never responds correctly is exactly the case a connection-only check reports as healthy.

The third piece: what happens after a connection drops

Connections dropping mid-session is its own documented pattern, and MCP's protocol doesn't specify a standard recovery behavior. Without an explicit reconnection strategy, a dropped connection just means the integration silently stops working until something notices.

Worth distinguishing two cases when you build this: a connection error should trigger reconnect-and-retry, but a real application error should propagate immediately. Retrying a genuine bug just turns a fast failure into a slow one.

If it's useful

We packaged these three pieces ΓÇö health checks that separate connected from working, reconnection with backoff, and a logger that can't corrupt a stdio transport ΓÇö into a small kit, tested with 11 cases including the exact silent-failure scenario above: MCP Server Reliability Kit.

The patterns themselves are straightforward enough to build yourself from the sketch above, and honestly that's a fine outcome too. The 52% number is the part worth taking away.