Cache misbehaves on version 1.3.4

[jneisener]

Description of the bug

We have simulations with and without header matchers. We noticed that on version 1.3.4 we get wrong results back from Hoverfly on requests that do not contain header matchers.

Steps to reproduce the issue

Difficult to describe in detail, but feel free to reach out I can demonstrate in a call (or expand the description here).

I'll try to illustrate, cannot share the entire recordings.
Request 1:

{
				"request": {
					"path": [
						{
							"matcher": "exact",
							"value": "/s4hanacloud/sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/$metadata"
						}
					],
					"method": [
						{
							"matcher": "exact",
							"value": "GET"
						}
					],
					"destination": [
						{
							"matcher": "exact",
							"value": "sandbox.api.sap.com"
						}
					],
					"scheme": [
						{
							"matcher": "exact",
							"value": "https"
						}
					],
					"body": [
						{
							"matcher": "exact",
							"value": ""
						}
					],
					"query": {
						"sap-documentation": [
							{
								"matcher": "exact",
								"value": "all"
							}
						]
					}
				},
				"response": {
					"status": 200,
					"body": "<Some xml>",
    				"encodedBody": false,
					"headers": {
						"Cache-Control": [
							"max-age=0"
						],
						"Content-Type": [
							"application/xml"
						]
					},
					"templated": false
				}
			},

Request 2:

				"request": {
					"path": [
						{
							"matcher": "exact",
							"value": "/path/to/resource"
						}
					],
					"method": [
						{
							"matcher": "exact",
							"value": "GET"
						}
					],
					"destination": [
						{
							"matcher": "exact",
							"value": "service.tld"
						}
					],
					"scheme": [
						{
							"matcher": "exact",
							"value": "https"
						}
					],
					"headers": {
						"SpecificHeader": [
							{
								"matcher": "exact",
								"value": "Specific-Value"
							}
						]
					}
				},
				"response": {
					"status": 200,
					"body": "<Some json>",
					"encodedBody": false,
					"headers": {
						"Content-Length": [
							"..."
						],
						"Content-Type": [
							"application/json"
						]
					},
					"templated": false
				}
			},

Observed result

Requests (with Hoverfly as proxy):

• GET https://service.tld/path/to/resource (with correct header)
  • Returns <Some json> (correct result)
• GET https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/$metadata?sap-documentation=all
  • Returns <Some json> (incorrect result)
• GET https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/$metadata (missing query)
  • No match found (correct result)

To me it looks like the lookup is done correctly (result is only returned on requests that exist in the simulation) but the returned result does not come from the cache if it matched, instead one of the simulations with a header matcher is returned (it seems to always be the same one).

Best guess: Related to #1006

Expected result

• GET https://sandbox.api.sap.com/s4hanacloud/sap/opu/odata/sap/API_OUTBOUND_DELIVERY_SRV/$metadata?sap-documentation=all
  • Returns <Some xml>

Additional relevant information

1. Hoverfly version: v1.3.4
2. Anything that might help us to diagnose the problem: does not happen on v1.3.3

[tommysitu]

Hi @johenning, #1006 has fixed a bug that enables the "eager caching". However I just found that your simulation could trigger a nasty bug in this feature.

Your Request 2 is not cachable because it has no "body matcher" (so not deemed as a recorded simulation), however it got cached nevertheless, because the following func pass the request-response pair pointer rather than the value:
https://github.com/SpectoLabs/hoverfly/blob/master/core/matching/cache_matcher.go#L98

func (this *CacheMatcher) SaveRequestMatcherResponsePair(request models.RequestDetails, pair *models.RequestMatcherResponsePair, matchError *models.MatchError) (*models.CachedResponse, error) {

what happened is that after Request 1 is cached, the pointer is assigned to reference Request 2, and eventually the cache would contains:
[hash of Request 1] -> Request 2

And when you made a call that matches Request 1, hoverfly will get Request 2 from the cache, and then return the Request 2 response.

[tommysitu]

The workaround for now is to disable caching: hoverfly -disable-cache. I will try to get a bug fix version out as soon as I can

[tommysitu]

fixed in v1.3.5