How App configuration is applied
Each App has one platform-managed customer configuration. Portal changes update that desired configuration before synsmarts applies it to the running App.
Desired state and running state are different
Section titled “Desired state and running state are different”The desired configuration describes what should run. The running configuration describes what the App has applied so far.
During an active change, the desired revision can be newer than the running revision. The operation status tells you whether the new revision is pending, applying, complete, failed, or superseded.
Validation happens before apply
Section titled “Validation happens before apply”synsmarts validates:
- the configuration structure and supported schema version;
- resource allocations against the purchased shape;
- required service minimums;
- supported service settings and exact versions, including matching engine/version pairs;
- variable names and permitted secret references;
- App ownership and revision consistency.
An invalid edit is rejected before it changes the running App.
Revisions prevent lost updates
Section titled “Revisions prevent lost updates”An edit is based on the App revision you loaded. If another accepted change lands first, the stale edit is rejected rather than overwriting it. Load the latest revision, review the newer change, and repeat your edit.
Save and apply are separate choices
Section titled “Save and apply are separate choices”Some screens allow Save for next restart. This records the desired change without restarting services immediately. Apply now records the same desired change and starts the required App operation.
The saved desired revision remains authoritative while an apply is pending or being retried.
Applies differ in weight
Section titled “Applies differ in weight”How a change applies depends on what changed. Some service settings apply live, without a restart. Others restart the affected service, and a restart in the web request path serves a brief maintenance response instead of raw errors. Structural changes, such as resources or service versions, rebuild the App’s configuration and roll it out, and the new configuration goes live only when the rollout completes.
A failed apply leaves the App on its previous configuration
Section titled “A failed apply leaves the App on its previous configuration”The App stays on its previous configuration until a change fully applies. When an apply fails, the desired change is preserved, the App’s configuration status reports the failure and its reason, and synsmarts retries. A change that has already completed isn’t reverted by a later failure. If a failed state persists, get support.
Customer-repository configuration is import input
Section titled “Customer-repository configuration is import input”A .synsmarts file in a connected customer repository can be imported through
an explicit workflow. It doesn’t become a continuously synchronized authority,
and later repository pushes don’t silently replace portal configuration.