A content publish broke our prod build, was it because we did not pin the slot version?
Someone on the content side published a schema change to a slot and our Next app immediately started getting content that did not match our types. Here is what I checked so far:
- the deploy that broke was not ours, no code changed
- the timing lines up exactly with the publish
- we fetch the slot without a version in the ID
My theory is that the missing version is the whole problem. Can someone confirm the safe practice before this bites us again
2 answers
Your theory is correct. When you omit the version in the slot ID it resolves to @latest, so the moment a schema change is published it takes effect on your live app, and if your code expected the old shape it breaks. Nothing on your side needs to deploy for it to happen.
The safe default is to pin a versioned slot ID, for example 'home-hero@2', either major or major.minor. Old versions keep serving after a schema change, so a pinned app keeps getting the shape it was written against until you deliberately bump the version and update the code together. In our case we pin everything and treat the version bump as part of the pull request that handles the new schema.
Pinned every slot ID this morning and it is stable now. Publishing on their side no longer touches us until we bump. Thanks
worth adding one related gotcha now that you are pinning, preview links also require the slot version to match. if you pin to @2 in code but the preview is built against a different version you get default content in the widget and think something is broken. more on that in this preview shows default content thread