Toolkit core rollback safety when apps expect newer core version

Question

ContextShotGrid (Autodesk Flow Production Tracking) applies server-side upgrades on a shared schedule with no customer rollback control. Recovery planning therefore centers on client-side Toolkit components: the versioned core API in the pipeline configuration's core folder and the pinned app/engine descriptors in environment YAML.Unresolved decisionWhen a core upgrade causes import errors or apps fail to load, the Toolkit CLI can revert the core to a prior version. However, if apps have already been updated to descriptors that declare compatibility with the newer core, no guaranteed core-to-app compatibility matrix is published. The operator must choose between a core-only rollback and a full configuration rollback, and custom apps written against the newer core may not load under the older core even when the rollback itself succeeds.GoalDetermine whether a core-only rollback is safe after apps have been upgraded to descriptors that expect the newer core, or whether a full configuration rollback is required to restore a working state.Is a core-only rollback ever safe once app descriptors have been updated to require the newer core? What signals indicate that a full configuration rollback is necessary instead? How can an operator verify compatibility before committing to either rollback scope in a production pipeline?

Tasadduq Burney · Answer

Answer to the Core‑Rollback Question
After app descriptors have been updated to require a newer core, a core‑only rollback is not guaranteed safe. The Toolkit runtime will reject any app that declares a minimum core version higher than the rolled‑back core, causing the app to fail at load time. Only if every descriptor either omits a core requirement or specifies a minimum core version that is satisfied by the older core can a core‑only rollback be considered safe.
Why a Full Configuration Rollback Is Needed When Descriptors Demand the New Core

Descriptor core field > rolled‑back core: runtime error – app load fails.
Descriptor core field exactly matches the new core: full rollback restores compatibility.
Hidden API changes between core releases can break apps even if the descriptor permits an older core.

Signals That a Full Rollback Is Required

Runtime log message: "Core version mismatch: required X, running Y".
Toolkit’s toolkit validate or toolkit check reports a descriptor’s core field greater than the current core.
Apps that were just upgraded and now fail to import or start.

Verification Steps Before Acting

Inspect descriptors – for each app and engine, open descriptor.yaml and read the core field. If any value is greater than the target rolled‑back core, a full rollback is required.
Run a dry‑run validation – execute toolkit validate --environment my-env (or toolkit check) to surface incompatibilities without making changes.
Test in a sandbox – deploy the rolled‑back core in a non‑production environment with the current descriptors. Observe whether apps load or fail.
Document findings and decide: if all descriptors are compatible, proceed with a core‑only rollback; otherwise schedule a full configuration rollback.

Missing Diagnostic Detail
To finalize the decision, we need to know the minimum core version declared by each app descriptor in the current configuration. This detail determines whether a core‑only rollback can be attempted safely.

Toolkit core rollback safety when apps expect newer core version

Context

Unresolved decision

Goal

1 answer

Answer to the Core‑Rollback Question

Why a Full Configuration Rollback Is Needed When Descriptors Demand the New Core

Signals That a Full Rollback Is Required

Verification Steps Before Acting

Missing Diagnostic Detail

Your perspective belongs here.

0 question comments