🦊 Netfox 0.22.1 β€” the row that vanished when macOS 27 landed

Hey everyone πŸ‘‹

Small release, but it's the kind I find interesting: nobody broke this one. It broke by itself, the day macOS 27 shipped.

Netfox tells you which operating system a device runs by reading a number the device advertises about itself. That number was supposed to track one thing, and it turns out it tracks another β€” the two just happened to agree for every release up to macOS 26. This year they stopped agreeing. So the table that turns that number into a name came up one row short, and every Mac that updated to macOS 27 quietly lost its OS row.

Here's why nobody reported it: the row didn't go wrong, it went absent. And an absent row looks exactly like a device that chose not to answer. There was nothing to see πŸ™ˆ

That's fixed in 0.22.1. The more useful half is the test. Every check in that suite compared against numbers typed into the suite itself, so the whole thing stayed green on a machine the table had never heard of β€” which is precisely the broken state. One of them even asserted that the next macOS was unknown, so it would have passed by agreeing with the bug.

There's now a check that asks the Mac it's running on whether Netfox can name its system. Green today, red the first day someone runs it on a macOS nobody has added a row for. Next divergence is a failing test instead of a blank line.

Nothing else in the app behaves differently in this one.

Update from Netfox β†’ Check for Updates…, or grab it at 🦊

Curious what you'd want to see next β€” happy to have the roadmap argued with.

63 views

Add a comment

Replies

Best

Fact that the row disappeared instaed of showing the wrong versions makes this really easy to miss. that a nasty kind of bug.

Β yyyeah, absent vs wrong is exactly the split - a missing row is indistinguishable from a device that simply declined to answer, and plenty do.. nobody reported this one; it surfaced because I went hunting through the macOS 27 upgrade for tables that enumerate versions πŸ˜…

Checking that next macOS is unknow sounds clever in theory but i can see why it wasn't enough once the actual behavior changed,

Β ngl you picked the bit I'm least proud of ....... and it's worse than "not enough": that check certified the bug instead of missing it. Asserting that the next macOS is unknown means the day build 27A ships, the suite goes green over a Mac whose OS row is blank. The replacment reads the build major off the machine running the tests instead of off me, so it can only stay green while the table knows the OS somebody is actually on

It's kind of scary that all the tests were green while the bug was already there. How are you handling these OS specific values now? feels like this could catch other weird changes too.

Β tbh the green suite bothered me more than the bug did. Every assertion in that file compared the table against numbers I'd typed into the file itself, so it could say nothing about the machine it was running on... the new check reads the build major off that machine and requires the table to name it, so it stays green only while the OS somebody is actually on has a row in there. Rows still get addded from a measurement, never by adding 1 to the last one, because that offset has already changed once.

The honest limit is that it goes red only once the suite runs on a Mac that has already updated, so it's a tripwire rather than a warning, and it covers exactly one table.. what generalises is the question rather than the test: anything that enumerates OS or model versions ages, anything that keys on a family name and throws the numbers away doesn't. That's why the model catalogue classified a Mac17,8 with nothing changed, while the version table needed a release

It's good example pf how an '' empty'' result can handle a real issue. Nobody seeing an OS row is very different from seeing the wrong OS.

Β an empty result is imo the worst shape a bug can take and you've put the general case better than I did - a wrong value gets screenshotted and sent to me, a missing one just looks like a device that didn't feel like answering... under the hood it's the same nil for both which is exactly why nothing in the app could tell them apart