WeDispatch 1.2.1: My audios, fixed — and the test that was missing

Version 1.2.0 redrew ten screens of the client area. One of them, My audios, opened on an error message. Not for everyone: only for accounts that had already produced at least one audio — which is to say, precisely for the people using it. Version 1.2.1 fixes it, and fixes the reason we did not see it coming.

What happened

The client area is rendered on the server, then the interactive parts — the search box, the filters, the "load more" button — take over in your browser. Between the two there is a boundary, and everything crossing it has to be expressible as text.

We had handed the audio list its dictionary of labels. It holds ready-made sentences, but also a few phrases that are computed: "12 of 40 audios shown", "Load 20 more audios", the plural that agrees on its own. Those are code, not text, and code does not cross the boundary. The server stopped at exactly that point, and the page returned an error.

The detail that kept it hidden: that list is only rendered when there is something to list. On an empty account — the one you naturally open when checking a redesign — the page displayed perfectly.

The fix

The labels no longer cross anything. They now live in a file that the server and the browser each read on their own side; only the chosen language passes between them. While we were there, the monthly usage panel was made defensive: if the database answers badly, the panel disappears rather than taking the whole page down with it.

The test that was missing

Our verification chain runs the tests then compiles the application before every release. It reported nothing, and that made sense: client-area screens are computed on demand, per account, with that account's data. They are never built at compile time, so compiling cannot watch them fail.

So we added a check that renders nothing at all: it reads the code, spots dictionaries containing computed phrases, and refuses to let them be handed to a component that lives in the browser. We first ran it against the faulty code to confirm it caught the bug, then across the nine other redrawn screens — My audios was the only one affected. That check now runs on every release.

What we take from it

A bug that only fires on active accounts is a bug you cannot see from a demo account. The lesson is not "test more", it is "test with data". That is our next piece of work: a verification pass that opens every dashboard screen with a genuinely loaded account, before you have to tell us. Thanks to the person who did.

Other release notes

• WeDispatch 1.4.0: telling the truth about what's reserved
• WeDispatch 1.3.0: the blog splits in two
• WeDispatch 1.2.0: your client area, redrawn