IBM Support

Published-Failed / Publish-Success State in API Connect Manager [New Feature v10.0.8.X]

Troubleshooting


Problem

You see in the API Manager UI  that the state of several or all products are depicted as "published-failed" after upgrading to v10.0.8.x or a publish/republish event.

Symptom

You are seeing a high event status in the Gateway Services portion of your catalog settings and/or a published-failed red X bubble in the state column of your catalog(s) after upgrading to v10.0.8.x or performing a publish/republish action.
High event status in the Gateway Services :

Image showcasing the gateway service showing a high event load in the catalog settings

Published-failed in state column of catalog :

Image showcasing the published-failed red X bubble in the state column of the catalog(s) after performing a publish/republish action.

Cause

The published-failed state is a new feature in v10.0.8.x that is meant to show if there was some type of error while the gateway compiled and created the objects.
The wording meant to show that the APIs published successfully but the gateway is pointing out that there were issues reported in the gateway configuration.

The status view will only report the first instance of the error and until the failure is addressed or the resource causing the failure is retired/removed, it will continue to be reported.

This is because the failure is seen when the catalog collection config sequence is run. If there is still a resource in the collection that causes a failure, you will get this published-failed state again until the failure is addressed for that resource or the resource is removed.

To navigate to the status view:

  • API Manager -> Manage -> <catalog name> -> Catalog Settings -> Gateway Services -> Click the three dots next to the gateway and choose “View Status”

Additionally, please note that this high status is not indicating that there is a high load on your Datapower appliance but rather that there were a number of errored events (anything more than 5) that were flagged by the gateway CLI.

As the message shows, this view will only report the first instance of an error that the gateway CLI reports.

  • Until the issue/failure is addressed and the resource causing the failure is retired/removed/fixed and republished, the gateway will continue to report a failure in the config which means that all subsequent publish or retire actions will have the 'failed' status appended to the action like you see now.

Image showing the failed event reported in the gateway processing status view

Diagnosing The Problem

Fear not! The product is working as intended and to move forward, the best practice is to download the collection logs identify what all errors are being reported by the gateway CLI so you can resolve them and clear the published-failed state.

Additionally, if you would prefer not to have the state column visible in your APIM UI, you can disable the view by following the steps outlined here:

  • Disabling the status feedback on products page.

  • Please note: Even after disabling the view in the UI, the state of the product lifecycle events will remain visible on the Gateway processing status pages so that the critical deployment information remains accessible to administrators. The issues reported should still be addressed even if they do not always cause a failure for the APIs.
Improved in v10.0.8.3+

It may also be helpful to mention that this feature has been improved from v10.0.8.3 from showing the red X and published-failed to a yellow warning symbol with published-success which notes that there is an issue with an API within the product and on the gateway processing status page, it now shows that there was a non-fatal error as opposed to saying just failed.

Published-Success with Warning label and Explanation in v10.0.8.3+
Image showing the published-success status with a warning and explanation
Gateway Processing Status shows non-fatal error instead of failed (where applicable)  in v10.0.8.3+
Gateway Processing Status now shows non-fatal error as opposed to failed
Addressing the Errors:
There are many reasons as to why this scenario could occur and it will be unique for each scenario.
In this example, the first error doesn't give many details in the status view so download the logs to look in the file flagged in the error message.

Image showing the error reported in the gateway config and where to look for more details.

Image showing the error reported in the gateway config and where to look for more details.

Resolving The Problem

  • Acquiring the Processing Status Logs from the previous step will download a zip file to your local machine.
  •  Unpack the zip and look for the .summary file for the affected catalog as shown below.
  • Within the example file below, there is one error reported in the configuration:
Image showing there is one error reported in the configuration:
The lines of importance are the ones delineated by the [error] marker.
{
      "message": "2025-07-22T15:26:53.071Z [0x088e00020][error] Configuration status: Failures in 20.kolinski_sample_collection.log",
      "stack": [
        "",
        "    at module.exports.addMessage (/opt/ibm/datapower/root/gateway-director/utils/summary.js:125:15)",
        "    at logger.buildMessage (/opt/ibm/datapower/root/gateway-director/utils/logger.js:188:15)",
        "    at logger.error (/opt/ibm/datapower/root/gateway-director/utils/logger.js:293:24)",
        "    at ApiGatewayConfig.wait (/opt/ibm/datapower/root/gateway-director/lib/gateway-controller/apigateway/ApiGatewayConfig.js:421:14)",
        "    at async ApiGatewayFileHelper.waitStatus (/opt/ibm/datapower/root/gateway-director/lib/gateway-controller/apigateway/ApiGatewayFileHelper.js:139:12)",
        "    at async ApiGatewayController.refreshCollectionConfig (/opt/ibm/datapower/root/gateway-director/lib/gateway-controller/apigateway/ApiGatewayController.js:1496:18)",
        "    at async ApiGatewayController._refresh (/opt/ibm/datapower/root/gateway-director/lib/gateway-controller/apigateway/ApiGatewayController.js:1294:26)",
        "    at async ApiGatewayController.refresh (/opt/ibm/datapower/root/gateway-director/lib/gateway-controller/apigateway/ApiGatewayController.js:1010:18)",
        "    at async /opt/ibm/datapower/root/gateway-director/lib/queueProcessor.js:1325:17",
        "    at async run (/opt/ibm/datapower/root/gateway-director/node_modules/p-queue/dist/index.js:163:29)",
        " ",
        "--- gateway-director context stack ---",
        "  context: ..."}",
        "  context: app.js"
      ]
    }
  ],
The message line points to the following file which is part of the zipped folder downloaded in the Gateway Processing Status logs to trace the issue:
[error] Configuration status: Failures in 20.kolinski_sample_collection.log",
Open the 20.kolinski_sample_collection.log file and search on [error]:

Tue Jul 22 2025 15:26:52 [apiconnect][0x8100021e][cli][error] cors-rule(kolinski_sample_invalid-allow-origin_1.0.1_cors_0): tid(23097) gtid(cde986dc11644333bd0a597a5865f7b):  '*' is not valid
Tue Jul 22 2025 15:26:52 [apiconnect][0x810001f3][cli][info] : tid(23097) gtid(cde986dc11644333bd0a597a5865f7b): (admin:apiconnect:system:*:20.kolinski_sample_collection.cfg:409):   allow-origin *
Tue Jul 22 2025 15:26:52 [apiconnect][][cli][error] : tid(23097) gtid(cde986dc11644333bd0a597a5865f7b): (20.kolinski_sample_collection.cfg:409):   allow-origin *
Tue Jul 22 2025 15:26:52 [apiconnect][0x81000243][cli][error] cors-rule(kolinski_sample_invalid-allow-origin_1.0.1_cors_0): tid(23097) gtid(cde986dc11644333bd0a597a5865f7b): required property allow-origin is missing
...
Tue Jul 22 2025 15:26:52 [apiconnect][0x81000243][cli][error] cors-policy(kolinski_sample_invalid-allow-origin_1.0.1_cors): tid(23097) gtid(cde986dc11644333bd0a597a5865f7b): required property rule is missing
According to the error, it looks as though the API invalid-allow-origin is using an invalid CORS configuration.
In this case, it is the wildcard * which is not supported as per
Image showing the API invalid-allow-origin is using an invalid cors configuration. In this case, it is the wildcard * which is not supported
Now that that the issue has been identified, it can be resolved by reviewing the API Connect Knowledge Center documentation:
  • Wildcards are not supported for the allow-origin values, you can enter only literal strings. Origins must follow the schema described in the fetch standard at https://fetch.spec.whatwg.org/#origin-header so, for example, port values can be entered but are optional.
  
The fixed API source:
The fixed API source:
  • To push the correct configuration to the gateway, the API and product must be republished. After doing so, the published-failed state should now display a published-success status with all event status flags having turned green. 
Now we must republish the API to push the correct configuration to the gateway and once we have done so, we will see that the published-failed state is now published-success and that all the event status flags have turned green. Now we must republish the API to push the correct configuration to the gateway and once we have done so, we will see that the published-failed state is now published-success and that all the event status flags have turned green. 
It is important to note that if there is still a resource in the collection that causes a failure beyond the republished product, you will still see the published-failed state again until the errored object is identified, fixed, and republished or retired.

Document Location

Worldwide

[{"Type":"MASTER","Line of Business":{"code":"LOB77","label":"Automation Platform"},"Business Unit":{"code":"BU048","label":"IBM Software"},"Product":{"code":"SSMNED","label":"IBM API Connect"},"ARM Category":[{"code":"a8mKe000000CaZVIA0","label":"API Connect-\u003EAPIC Gateway"}],"ARM Case Number":"TS018907401","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"and future releases;10.0.8"}]

Document Information

Modified date:
14 October 2025

UID

ibm17240262

Page Feedback