fastly/fastly-magento2

REST API GET request to /V1/bulk/:bulkUuid/status is cached and never updated

Closed this issue · 2 comments

We faced with an issue when you run REST API GET request to /V1/bulk/:bulkUuid/status is cached and never updated. However, on the Varnish it works correctly. Our merchant frequently complains, that Asynchronous Bulk Operations are very slow, but after investigation we figured out that the problem with the status requests because, that's only one API way how to check that All Bulk Operations were processed (yes exactly RabbitMQ UI also can help to understand that).

TEST CASE

  1. Run POST API request to https://your.magento/rest/all/async/bulk/V1/products. See documentation
  2. Save BULK_UUID from response
  3. Run GET API request to https://your.magento/rest/[default_store_code]/V1/bulk/[BULK_UUID]/status
  4. Run php bin/magento queue:consumers:start async.operations.all & on the server
  5. Repeat step 3 many times
  6. Even when RabbitMQ processed all product updates the status is not changed

EXPECTED RESULT
GET API request https://your.magento/rest/[default_store_code]/V1/bulk/[BULK_UUID]/status should not be cached

ACTUAL RESULT:
GET API request https://your.magento/rest/[default_store_code]/V1/bulk/[BULK_UUID]/status should is cached

ADDITIONAL INFORMATION:
Rest and soap requests should not be cached. See:
https://github.com/magento-commerce/magento2ce/blob/2.4-develop/app/code/Magento/PageCache/etc/webapi_rest/di.xml
https://github.com/magento-commerce/magento2ce/blob/2.4-develop/app/code/Magento/PageCache/etc/webapi_soap/di.xml
https://github.com/magento-commerce/magento2ce/blob/2.4-develop/app/code/Magento/PageCache/Plugin/AppendNoStoreCacheHeader.php
On the Fastly module side this case should be correctly handled:
https://github.com/fastly/fastly-magento2/blob/master/etc/vcl_snippets/fetch.vcl#L75

Theoretically we can use VCL snippet like:

# Snippet magentomodule_rest_api_bypass : 100
if (req.url.path ~ "/rest/*" ) {
   set req.http.x-pass = "1";
}

but it's just workaround.

Example of payload for step 1:

[
    {
        "product": {
            "attribute_set_id": 4,
            "visibility": 4,
            "type_id": "configurable",
            "name": "Example Product 1",
            "weight": "0",
            "extension_attributes": {
                "stock_item": {
                    "manage_stock": true,
                    "qty": 10000000
                }
            },
            "sku": "example_sku_1",
            "status": 1,
            "custom_attributes": [
                {
                    "value": null,
                    "attribute_code": "short_description"
                },
                {
                    "value": "61",
                    "attribute_code": "example_attribute"
                }
            ]
        }
    },
    {
        "product": {
            "attribute_set_id": 4,
            "visibility": 4,
            "type_id": "configurable",
            "name": "Example Product 2",
            "weight": "0",
            "extension_attributes": {
                "stock_item": {
                    "manage_stock": true,
                    "qty": 10000002
                }
            },
            "sku": "example_sku_2",
            "status": 1,
            "custom_attributes": [
                {
                    "value": null,
                    "attribute_code": "short_description"
                },
                {
                    "value": "62",
                    "attribute_code": "example_attribute"
                }
            ]
        }
    }
]

In general we rely on Magento providing us the cache headers whether something should be cached or not. If that specific REST call is being cached it would imply that cache control headers are telling us to do so. I am hesitant to add VCL to skip those as there are definitely REST things that can be cached.

@vvuksan I apologize for this issue. That's was a problem with Fastly configuration on the merchant side.
Closing. Anyway thank you so much for looking.