Test with Siesta changed behavoir

[jordanpwood]

I have a test which exercises Siesta and the persistent cache that I wrote that Siesta uses. Today I noticed that this test is failing, when it used to work. In the test I setup a resource, call loadIfNeeded, then when I get a .newData with the event source .network (the actual network call uses URL mocking), I wipe the resource, and then wait for another .newData with a source of .wipe, then load the resource again. I expect this to get data from my cache which got populated by the first load. However, it seems that the resource is making a new request before the cache has returned a result. Is that expected? Is there supposed to be a race between the request and the cache hit, and I just got lucky before? If so, got any suggestions on how to change my test?

[jordanpwood]

To be clear, the problem is that I get an error result from the URL mock because I sent it an extra, unexpected get request. Also, it defeats the purpose of the test if I can't force the data to come from the cache.

[pcantrell]

Is there supposed to be a race between the request and the cache hit

Yes, in a word. The .newData(.wipe) is synchronous, but the cache read is asynchronous — as is the network request, of course. That’s why, after receiving a cache hit, Siesta checks whether the resource already has data and if so ignores the cached data.

This means that you can see two different sequences of events depending on whether the network or the cache wins the race:

Cache wins

1. .newData(.wipe)
2. .newData(.cache)
3. .newData(.network)

Network wins

1. .newData(.wipe)
2. .newData(.network)
3. (cache hit ignored)

In real apps, the cache is very likely to beat the network, but I can imagine a mocked network winning. The solution to your problem is to pause the mocked network response until you see the cache hit. That’s something the Siesta specs have to do a lot of — and unfortunately I had to fork Nocilla to do!

[pcantrell]

Hmm, on second thought, you could also fix your problem by waiting for .newData(.cache) instead of just .newData(.wipe). Would that ruin the point of your test?

[jordanpwood]

Thanks Paul, you saved my test! I didn't realize that I'd get a cached response after a wipe. I'm good to go now.

[pcantrell]

I didn't realize that I'd get a cached response after a wipe.

Yeah, that’s not obvious, and it took some serious thought to get there. The short of it is that wipe()’s contract is to restore the resource to the state it would be in if it has just been instantiated for the first time — and resources check the cache on creation.