Loading

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

Date de publication: Jun 10, 2026
Description

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.

Résolution

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.

Numéro d’article de la base de connaissances

005386646

 
Chargement
Salesforce Help | Article