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
nullis 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.
