strip_listen_path Set to true Unexpectedly After Tyk Upgrade – Tyk

Overview

In some Tyk Dashboard versions, APIs may have strip_listen_path set to true unexpectedly after a TYK upgrade, even when the strip field is not specified in the OAS API definition.

This behavior is related to the force_api_defaults configuration.

Cause

The Dashboard code defines the default value of force_api_defaults as false. However, the bundled tyk_analytics.conf configuration contains:

"force_api_defaults": true

Testing showed that in Tyk 5.8.x, this bundled configuration value was not being applied, so the effective value remained false.

In Tyk 5.13.1, the bundled configuration value was applied, causing the effective value to become true.

When force_api_defaults is set to true, Dashboard forces strip_listen_path to true when an API is updated. This is what caused the existing APIs to change from false to true after the upgrade.

Resolution

Explicitly set the following environment variable on the Dashboard deployment:

TYK_DB_FORCEAPIDEFAULTS=false

Restart the Dashboard deployment after applying the configuration.

Newly deployed APIs should then be created with:

strip_listen_path: false

and the Dashboard UI should display the expected false value.

Existing Affected APIs

Setting TYK_DB_FORCEAPIDEFAULTS=false prevents the issue from occurring for newly deployed APIs, but APIs that were already affected will need to be redeployed.

Operator deployment/Resync will not work

Triggering an Operator resync by changing an annotation alone will also not necessarily correct the affected APIs:

kubectl -n <namespace> annotate tykoasapidefinition <name> resync="$(date +%s)" --overwrite

Since the API specification hash has not changed, the Operator does not consider the API configuration to have changed and will not reprocess it. Therefore, the annotation or an Operator restart/redeployment alone will not fix the existing affected APIs.