I published the lesson but nobody can see it

You write a lesson, press Publish, and the screen confirms it: Published. The person it was written for opens their tablet and sees an empty list. No error, no message saying why, nothing. Just no lesson.

That is what happened in a children’s learning app. A parent wrote a lesson and published it, and the child’s tablet showed nothing. The same gap would exist in any training or course platform where publishing and assigning are separate steps: the content is live, and the people it was meant for have not been given it. Nobody is told, and the screen says everything went well.

What was actually going on

I found it by looking at the database rather than opening the app, which is why it took minutes instead of an afternoon. The table that records which lesson was given to which child had no rows in it at all.

The child’s tablet asks the server for its lessons, and the server checks two things: that the lesson has been given to this particular child, and that the lesson has been published. Both must be true. If either is missing, the list is empty, and the list cannot tell “nothing given” from “given but still a draft”.

The parent had made exactly one of the two true. Publish was a large button on the lesson editor. Giving the lesson to a child was a separate action, reachable from one place: a menu behind three dots, on the lessons list, a screen back. Someone writing, reviewing and publishing never passes through it. They did everything the screen asked of them, and then saw a “Published” label that was true of the lesson and misleading about whether anyone would see it.

The server had been right all along, and its automated checks already covered every combination of the two conditions. Every one of those checks was correct, and none could have caught this. They prove the rule is enforced. They cannot show whether a person is able to satisfy it.

What we changed

The tempting fix is a forced step that makes you assign before you can publish. We did not do that, because it makes the common case worse for a parent who has already assigned the lesson and just wants to publish an edit.

Instead, the editor now shows, permanently in its footer, who the lesson is for, or says that it has not been sent to anyone and offers to choose. It shows this on drafts too, so the parent learns the lesson reaches nobody before pressing Publish, not after. Publishing with nobody chosen opens the picker rather than leaving a “Published” label over a dead end. And if the household has exactly one child, publishing assigns to her straight away, because a choice with one possible answer is an obstacle.

What it did not fix

A push notification was suggested, and it would not have helped. The child’s list is something the tablet asks the server for. A notification that arrived perfectly would have opened the app on exactly the same empty list, because the emptiness was in what the server returned, not in how it was delivered.

Notifications tell someone to go and look. They do not change what is there when they arrive.

Two red herrings also cost time. One was two households with similar names, which a single query ruled out. The other was two log files that looked relevant: one held activity from the previous version of the product, weeks earlier, and the other held identifiers from a development database that do not exist in production at all. An identifier that cannot exist in the system you are investigating proves the file is not about that system.

The pattern, for anyone running a course or training platform

Whenever something becomes visible only when two things are both true, ask which screen makes each one true, and how many steps separate them. If they are on different screens, the condition that is not beside the confirmation button is the one that will be missing in real use.

Then check what your “Published” or “Done” label really promises. If it is true of the content and silent about whether anyone can see it, somebody will eventually publish something and assume it arrived.

Where this ends up

Checking that a person can actually satisfy a rule, and not only that the server enforces it, is part of how we build and review custom software.