Breaking change on JS middleware drivers in 4.2.2

[ca-simone-chiorazzo]

Branch/Environment/Version

• Branch/Version: 4.2.2
• Environment: On-prem

Describe the bug
In 4.2.2, a breaking change related to JS middleware driver has been released.
Basically, now you have to define
"driver": "otto

in each of the custom_middleware section of every API definition.

If you don't do that (it was not required until 4.2.1), you get the following error during the startup of the gateway:

tyk-webapp-1 | time="Nov 25 08:47:28" level=error msg="Unsupported driver ''" prefix=coprocess

Reproduction steps
Steps to reproduce the behavior:

1. Use tyk 4.2.2
2. Add whatever API that leverage a JS middleware
3. Avoid to set the 'driver' in 'custom_middleware' section
4. Startup the service, you'll see the error mentioned above

Actual behavior
A clear and concise description of what you expected to happen.

Expected behavior
If the change was expected, we would expect to be released as a breaking change.

Configuration (tyk config file):

{
  "listen_port": 8092,
  "secret": "6995d0304dad43d8ac6187264a7bceb9",
  "template_path": "/opt/tyk-gateway/templates",
  "tyk_js_path": "/opt/tyk-gateway/js/tyk.js",
  "middleware_path": "/tyk/middlewares",
  "use_db_app_configs": false,
  "app_path": "/tyk/apps",
  "storage": {
    "type": "redis",
    "host": "tyk-redis",
    "port": 6379,
    "username": "",
    "password": "",
    "database": 11,
    "optimisation_max_idle": 2000,
    "optimisation_max_active": 4000
  },
  "enable_analytics": false,
  "health_check_endpoint_name": "health-check/",
  "health_check": {
    "enable_health_checks": false,
    "health_check_value_timeouts": 60
  },
  "optimisations_use_async_session_write": false,
  "enable_non_transactional_rate_limiter": true,
  "enable_sentinel_rate_limiter": false,
  "enable_redis_rolling_limiter": false,
  "allow_master_keys": false,
  "policies": {
    "policy_source": "file",
    "policy_record_name": "/tyk/policies/policies.json"
  },
  "hash_keys": true,
  "close_connections": false,
  "http_server_options": {
    "enable_websockets": true
  },
  "allow_insecure_configs": true,
  "coprocess_options": {
    "enable_coprocess": true,
    "coprocess_grpc_server": ""
  },
  "enable_bundle_downloader": true,
  "bundle_base_url": "",
  "global_session_lifetime": 100,
  "force_global_session_lifetime": false,
  "max_idle_connections_per_host": 500,
  "enable_jsvm": true
}

Additional context

We were not aware of the driver configuration. Since it's defined as a root property of custom_middleware section, does this mean that you can't have a Python middleware and a JS middleware running on the same API definition?

[oluwaseyeayinla]

@ca-simone-chiorazzo This is not a bug and is now a requirement. Part of the change was because some users wanted to use go plugins but the driver was automatically set to JavaScript and the gateway would implode.

does this mean that you can't have a Python middleware and a JS middleware running on the same API definition?

I believe so. I don't think have I seen any implementation like this. Maybe you can explain the goal or design decision?

[andyo-tyk]

Closing, as Olu has answered the original question. If you have any further questions or can describe the use case you're looking to implement then please don't hesitate to comment and we can reopen the ticket.

Thank you for supporting Tyk!

[tstrike]

FWIW - We're coming across this late, but both 4.3 release notes and 4.2 release notes indicate 'Follow the standard upgrade guide, there are no breaking changes in this release.', but this change broke our upgrade when we moved from 4.0.x to 4.3.2 and our API requests started to fail for no obvious reason (missing auth middleware). So while this may have been done by design as an enhancement, I think the call-out here is for better documentation, review and acknowledgement of potential breaking changes.