Case Study on BXM.net

A Config Diff of 128 Lines Hid Two Real Changes, and Canon Named Both in Two Lines

Thu, 22 Oct 2026 00:00:00 +0000

Here’s a familiar review. The config for a checkout service comes back from someone’s editor and the diff is a wall of red and green. The editor saved with four spaces instead of two, sorted the keys, and escaped the “ü” in the description. Somewhere in there, maybe, a value changed.

We built that situation on purpose. One service config of 66 lines covers the server, database, cache, limits, features, logging and deploy settings. The deploy tool writes it one way. An editor saves it another way and changes two values on the way: the database pool timeout drops from 30000 ms to 3000 ms, and the replica count turns from the integer 3 into the float 3.0.

Hashing 100,000 JSON Lines Found No Duplicates, Hashing Them With Canon Found 9,900

Thu, 22 Oct 2026 00:00:00 +0000

Event pipelines get the same event twice. A producer times out, retries, and the retry goes through a different service that writes JSON its own way. The usual dedupe is a hash of each line, and it quietly misses all of these.

We generated a stream of 100,000 JSON lines from a fixed seed, 13.1 MB in all. 90,000 are distinct purchase events. The other 10,000 are resends of earlier events, written by two other producers. One sorts the keys and escapes non-ASCII, so “Zürich” arrives as Z\u00fcrich. The other reverses the key order and adds spaces. For a twist, 100 of the resends come from a producer that writes the quantity as a float: 2.0 where the original said 2.

Memo in GitHub Actions Skipped a Rust Release Build and Caught Runners With Different Compilers

Thu, 22 Oct 2026 00:00:00 +0000

Most CI jobs build the same thing again and again. A docs fix or a typo in a README triggers the whole pipeline, and the release build runs as if the code had changed. This case study puts BXM Memo in front of one such step, a release build of the bxm-canon binary, and keeps Memo’s cache between jobs with actions/cache.

The workflow is in the repository as .github/workflows/case-study-memo.yml. Five jobs run one after another, each on a fresh GitHub-hosted runner. plain builds without Memo for the baseline. cold builds through Memo with an empty cache, warm changes nothing, docs edits the README, and source edits a Rust source file. The inputs are canon/src/**, Cargo.toml and Cargo.lock, and the salt is rustc --version, so a different compiler means a different result. We ran the whole workflow twice.

One Order Built in Python, JavaScript and by Hand Gives Three JSON Hashes and One Canon Hash

Thu, 22 Oct 2026 00:00:00 +0000

A checkout service written in Python signs each order before it hands it on. A fulfilment service written in JavaScript checks the signature before it ships anything. Both have the same order in memory. The question is whether they agree on its bytes.

We built one order three ways. Python filled a dict in the order its code reads, and json.dumps wrote it with its defaults: a space after every comma and colon, and “Zürich” escaped as Z\u00fcrich. JavaScript built the same object with its keys in another order, and JSON.stringify wrote it compactly with the ü left as it is. The third copy is a file written by hand, pretty-printed, with yet another key order, hashed with the bxm-canon command.

Replaying 13 Commits Through Memo Cut Test Time From 228 to 79 Seconds and Turned Up Two Flaky Tests

Thu, 22 Oct 2026 00:00:00 +0000

BXM’s repository has two packages with their own test suites: Canon, tested with cargo test, and Memo, tested with go test. Most commits touch one of them, or neither. A docs change or a new JavaScript build script doesn’t change either suite’s result, yet a plain CI job runs both every time.

So we replayed the repository’s own history. All 13 commits from 0.1.0 to the end of 0.3.0 were checked out one after another, and both suites ran at each one. That happened twice: once plain, and once with each suite behind Memo. Canon’s suite takes canon/** and the spec’s test vectors as inputs. Memo’s takes memo/**. Memo needs a declared output, so each suite writes its log to a file and that file is the output.

Why Did My Build Step Run Again, Six Cache Misses and What Memo Said About Each

Thu, 22 Oct 2026 00:00:00 +0000

A cache that misses without saying why is almost as annoying as no cache. Someone notices the step ran again, nobody knows why, and the cache key gets a random suffix “to be safe”. After that the cache never hits.

BXM Memo keeps the manifest of the last run of each named job. On a miss it compares the two and says what changed. We put that to work on a small report step: a Python script that totals sales per region from monthly CSV files into out/report.txt. The step runs through Memo with the script and data/*.csv as inputs, REPORT_CURRENCY as an environment variable that changes the result, and the Python version as the salt.