Step 4 — Change something, and learn what the platform ignores¶
About 15 minutes. Branch: step-4.
The one new idea: an unknown key in appmecca.yaml is dropped in silence.
First, a visible change¶
Add a count to each column heading in frontend/src/Board.jsx:
<h2>
{column.label}
<span className="count">
{items.filter((item) => item.status === column.key).length}
</span>
</h2>
Push and deploy, and keep the site open in a browser while it runs. Refresh every few seconds. At some point the counts appear, and at no point does the page fail to load.
That is a blue/green deploy: the new version is started and proved healthy alongside the old one, then traffic moves, then the old one stops. There is no window where nothing is serving.
Now the important part¶
Add these two lines to your web service and deploy:
Watch what happens.
The deploy succeeds. No error, no warning, nothing in any log. And your app has one replica and no health check, exactly as before.
Unknown keys are discarded silently. A typo in a key name is not a mistake the platform will tell you about — it is a change that does nothing, and you will believe it worked.
This is the single most expensive gotcha on the platform
There is no message to search for, because there is no message. When something you configured is not happening, read the key names character by character before you look anywhere else.
mecca debug tally -b tutorial is the tool that gets closest: it shows what
the app actually received, so a variable you set and cannot find is visible
as an absence.
Take those two lines back out. They were never doing anything, and leaving them would leave the next reader of your repository believing they were.
While you are here: resources.cpu¶
That is accepted and does nothing. It is not a typo — the key is real, it parses,
and no part of the platform reads it. resources.memory is honoured; cpu is
not. Do not reach for it.
And: the first stale bundle¶
If you deploy a change and the page does not update, before you doubt the deploy:
Your site sits behind an edge cache. From step 16 you will configure that deliberately; until then, this is the escape hatch.
What you should see¶
- Counts on the columns, arriving without a moment of downtime.
- A successful deploy that did nothing at all, twice.