We had a beta date. We are not going to make it, and the reason is worth writing
down rather than quietly moving the date.
## A component that returned nothing
While auditing the control panel we opened `src/components/ui/confirm-dialog.tsx`
and found a component whose entire body was `return null`. It carried a comment
marking it a placeholder for type-checking.
It was imported by **118 files**.
Every destructive action in the platform routes through that dialog — stopping an
application, starting it, cancelling a subscription, deleting an app, removing a
Kubernetes pod, deleting a CRM record, revoking a certificate. The action only
fires from the dialog's confirm button. With the dialog rendering nothing, the
button did nothing.
Click *Stop*. No dialog appears. Nothing happens. No error, no log line, no
failed request. The app stays running.
## Why nothing caught it
This is the part that changed how we test.
- **TypeScript passed.** The props were correct. A component returning `null` is
perfectly valid.
- **The build passed.** It rendered fine — it rendered nothing.
- **A test asserting "the Delete button is visible" would have passed too.** The
button was always there.
The failure was invisible to every automated check we had, because it failed
*successfully*. Nothing was broken in a way a machine could see. You had to click
it and notice that your app was still up.
We have since added a lint rule that fails any component whose body is only
`return null`, and we are writing end-to-end tests for the destructive controls
specifically, which had no coverage at all.
## What else the same audit found
Once we started pulling, the pattern repeated:
- The client dashboard's "Active Applications" figure read a database table with
**zero rows** in it. Clients with running applications saw `0`. The real
applications live in a different table; a duplicated subsystem had been left
behind and the dashboard was querying the dead one.
- Those same dashboard counts were not scoped to the signed-in client. "Team
Members" counted every staff account on the platform.
- The catalogue restriction could be bypassed by sending a different field in the
deploy request.
- Paying for hosting sent no receipt. The payment-confirmation email existed, but
only on a code path for a marketplace that no longer exists.
None of these were reported by a customer, because we do not have customers yet.
That is precisely the argument for delaying rather than launching.
## The new date
We are not giving one yet. We will announce a beta date when we have driven a
complete project through the platform by hand — subscribe, provision, order,
contribute, invoice — as a customer would, rather than when the test suite is
green. The test suite was green for all of the above.
The next two posts cover what else we found and fixed: a discount mechanic that
was impossible to earn, and the credential isolation work that came out of it.
Enjoyed this article?
Subscribe for more insights on DevOps, security, and developer tools. No spam, unsubscribe anytime.