Gateway defaults to v3 execution mode while apim defaults to v4

[exalate-issue-sync]

Describe the bug :

When APIM receives an API with no execution mode, the mode is v4 emulation engine. But when the gateway receives this kind of API, the mode is v3. The behaviour should be consistent between gateway and apim in order to ensure that API coming from third party component, like the kubernetes operator, behave consistently.

To Reproduce :

Define in Policy Studio in Response phase those 2 policies: Attachment - image.png Groovy policy should contain in On-response content script

context.attributes.'test_adding_attributes' = "dummy_attribute"response.headers.'test_adding_headers' = "dummy_header"

Test logger policy is custom policy we created which just consist of single step that is responsible for printing context attributes and response headers to log (zip with full custom policy available in attachment)

@OnResponseContent public void OnResponseContext( Request request, Response response, ExecutionContext executionContext, PolicyChain policyChain )

{ Map[String, Object] attributes = executionContext.getAttributes(); log.info("--------------------------------------------------------"); log.info("Execution context:"); log.info("--------------------------------------------------------"); attributes.forEach((key, value) -> log.info(key + ": " + value)); HttpHeaders headers = response.headers(); log.info("--------------------------------------------------------"); log.info("Response Headers"); log.info("--------------------------------------------------------"); headers.forEach((header) -> log.info(header.getKey() + ": " + header.getValue())); }

(side note. To enable logging for custom plugins we had to change loggers configuration by changing:

gateway: logging: debug: true graviteeLevel: INFO additionalLoggers: - name: com.xxx level: DEBUG

)

To test it deploy that API manually by UI and perform a request. It should create in APIM Gateway logs entries with

apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - --------------------------------------------------------apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - Execution context:apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - --------------------------------------------------------...apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - test_adding_attributes: dummy_attribute...apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - --------------------------------------------------------apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - Response Headersapim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - --------------------------------------------------------...apim-gw-6759446f4f-xj2fc apim-gw 10:41:58.367 [vert.x-eventloop-thread-1] [] INFO c.k.api.management.ContextLogger - test_adding_headers: dummy_header

and it does - _ OK _ .

Deploy same API with GKO and perform a request to this API. In logs we can still see that Test logger policy has been executed, but it doesn't have neither context attribute test_adding_attributes nor response header test_adding_headers - _ KO _

Environment 4.0.2

• Please see Zendesk Support tab for further comments and attachments.