Closed jameslaneconkling closed 7 years ago
@jameslaneconkling thanks for raising this issue. I can't remember off the top of my head what the behavior is when $type: 'error'
instances are returned from the data source, but I'll look into the source/tests and get back to you soon.
READ THE DOCS!. My bad: $expires: 1
, does not actually mean expire in 1 sec, but actually don't ever expire. $expries: 0
almost works, but causes an infinite request loop when the model can't find the just-requested values in the cache. $expries: -1
does the trick.
Sorry for the confusion. All is well in the world.
@jameslaneconkling ah, yes. Negative $expires values are used to indicate relative expiry times (in ms) from when the value was inserted, and > 1 $expires values are presumed to be absolute expiry times (unix timestamps from the epoch), such as "expire this value after March 24th at 8pm."
For context, this is in relation to this ticket. Requests that return 400/500 populate the graph w/ error sentinels, and subsequent retries simply hit the cache, rather than actually making the API call again. Being able to set expiry metadata on sentinels returned from the datasource would solve this. But it looks like metadata is not actually applied to nodes in the cache (though if I'm reading this correctly, it looks like it should...).
E.g.
I still need to confirm whether or not this is happening in the original Netflix implementation.