Loading

CloudHub2 Application Fails to Start After Auto-Patch Due to Runtime and Application Artifact Mismatch

Publiceringsdatum: Jun 10, 2026
Beskrivning

PROBLEM:
After a CloudHub2 application experiences a deployment failure (e.g., due to insufficient resource allocation) and subsequently undergoes an automatic runtime patch, the application may fail to start or enter a continuous restart loop.
You may observe errors in the application logs similar to:
```
Artifact XX requires a newest runtime version.
```
or other compatibility errors indicating that the application artifact is incompatible with the currently assigned Mule Runtime version.

ROOT CAUSE:
CloudHub's continuous update mechanism includes an auto-patch feature designed to revert an application to its last known successful runtime configuration if a subsequent deployment or update fails. This process aims to restore application stability.
However, while the auto-patch reverts the *Mule Runtime version* to a previous successful state (e.g., from a Java 17-compatible runtime to a Java 8-compatible runtime), it *retains the latest application artifact* (JAR file) that was deployed.
If the latest application artifact was built or configured to require a newer Mule Runtime version (e.g., Java 17) than the one the auto-patch reverted to (e.g., Java 8), a compatibility mismatch occurs. This mismatch prevents the application from starting successfully on the older runtime, even though the auto-patch intended to restore a working state. The initial deployment failure (e.g., vCore allocation issues) acts as the trigger for this auto-patch behavior.

Lösning

To resolve or prevent this issue, ensure that the deployed application artifact is compatible with the assigned Mule Runtime version.

1.  **Identify the Current Runtime and Application Artifact Versions:**
    *   Navigate to your application in Anypoint Platform Runtime Manager.
    *   Check the "Settings" tab to see the currently assigned Mule Runtime version.
    *   Review the deployment history or audit logs to identify the version of the application artifact (JAR file) that was last deployed and the runtime version it was intended for.

2.  **Address the Initial Deployment Failure (if applicable):**
    *   If the auto-patch was triggered after a resource allocation issue (e.g., vCore limits), resolve that underlying problem first. Increase vCore allocation or adjust application resource requirements as needed.

3.  **Redeploy with Compatible Versions:**
    *   **Option A: Redeploy the application with the correct, newer Mule Runtime version.**
        *   In Anypoint Platform Runtime Manager, go to your application's "Settings".
        *   Update the "Runtime Version" to match the version required by your application artifact (e.g., if your artifact requires a Java 17-compatible runtime, select an appropriate Mule Runtime version).
        *   Save the changes. This will trigger a redeployment.
    *   **Option B: Redeploy an application artifact compatible with the reverted Mule Runtime version.**
        *   If you prefer to keep the older Mule Runtime version, you must deploy an application artifact (JAR file) that was built and tested to be compatible with that specific runtime version.
        *   Upload the compatible application artifact via Anypoint Platform Runtime Manager or your CI/CD pipeline.

4.  **Monitor Application Status:**
    *   After redeploying, monitor the application logs and status in Runtime Manager to ensure it starts successfully and operates as expected.

Knowledge-artikelnummer

005386646

 
Laddar
Salesforce Help | Article