Removed from the app, yet her tablet still worked

You remove somebody from your system and you expect the door to close behind them. In a children’s learning app, a parent removed a child and added her straight back, just to see what would happen. She lost everything, and her old tablet kept working.

Twelve lesson assignments, eight progress records, eleven quiz attempts, four hundred points and one task all stayed attached to the record that had been removed. The tablet, paired again, signed in as the newly created child and showed an empty list. Meanwhile the sign-in issued to that tablet under the old record was still valid.

The risk is plain for any business: a person you removed can still get in, and a person you added back returns with no history. It was found by someone using the product normally for about fifteen seconds.

What was actually going on

Removing a child did not delete her. It hid her: the record stayed, stamped as removed, and every list was supposed to leave her out. For a record with a lot of history hanging off it, that is a sensible choice.

Adding a child simply created a new record. Nothing checked whether a removed child with the same name already existed. So remove followed by add was not a round trip. One person became two records, one invisible and holding all the history, the other visible and empty. On screen the name disappeared and came back, so the natural assumption was that nothing had been lost.

The tablet’s sign-in was the part we would flag hardest. The parent believed the tablet had been disconnected. The system believed a sign-in existed, pointed at a record that still existed, and was therefore valid. Removing a child did not cancel her devices’ access.

There was a rule in the database that looked as if it covered this: remove a device and its sign-ins go with it. But both ways of removing a device only hide it, so the rule never ran. A safeguard written for real deletion does nothing in a system that never really deletes, and it is worse than having none because it looks like cover.

Reading the code turned up the same problem in other places. The “hidden” marker was missing from the query behind the children list and the household dashboard, so hiding a child hid her from neither. It was missing from six other queries too, including one that would have raised a “not synced recently” alert about a removed child’s tablet for ever. And the step that turns a child in a web address into a record still found removed children, so a second removal request said success and did nothing.

What we changed

Removing a child now cancels the sign-ins on her devices in the same step, so the removal cannot be cosmetic. Three automated checks cover it, and each was confirmed to fail when the fix is taken out. The lost history was recoverable: the rows were all still there, and moving them onto the surviving record was a single careful operation.

For the re-adding problem, the honest choices are few: refuse and offer to restore, restore quietly and say so, or make the delete real. Doing nothing picks a fork. We recommended one of the first two.

What it did not fix

The source for this article records the finding and the credential fix. It does not record which of the recommended answers for re-adding shipped, or that every query now leaves removed children out, so this write-up does not claim either.

Some things should not be hidden at all. A reward removed from the store is switched off rather than deleted, because past redemptions point at it and a real delete would erase what a child bought. A cancelled savings goal is kept for the same reason: points committed to it are accounting entries that must not lose what they refer to.

The pattern, for anyone who removes people from a system

Ask what removing a person actually does. Does it end their access, every device and every sign-in, in the same moment? Does adding them back restore what they had, or start a stranger?

The test for deleting is simple. Delete for real when nothing points at the record. Hide it when something does, and then make every list, every lookup and every sign-in aware that it is hidden. Hiding and hoping the lists filter correctly is how you end up with two people of the same name, one of whom owns the history and cannot be seen.

Try it yourself: remove a test user, then see whether their phone, their tablet or their saved login still works.

Where this ends up

Access that outlives a removal is the kind of fault we look for when we take on custom software development, because it is invisible on every screen and only shows when somebody tries the door.