Deno.KV expireIn time

[saeho]

Either there's a bug, or I don't understand how {expireIn} works or the documentation is not right.

I'm doing:

await kv.set(key, value, { expireIn: 4000 });

In this code, I'm expecting the key/value to expire and return null after 4 seconds (4000 milliseconds).

However, the get() function continues to work.

It eventually does expire, but not in 4 seconds or 4000 seconds. Is this a bug?

[lucacasonato]

Expiry happens some time after the set time, but not necessarily immediately after that time. This is documented in the docs:

https://deno.land/[email protected]?s=Deno.Kv#method_set_0

Optionally an expireIn option can be specified to set a time-to-live (TTL) for the key. The TTL is specified in milliseconds, and the key will be deleted from the database at earliest after the specified number of milliseconds have elapsed. Once the specified duration has passed, the key may still be visible for some additional time. If the expireIn option is not specified, the key will not expire.

[th0rgall]

I also had a bug due to this, because I missed this caveat, but I found it eventually.

The way it's specified now, an implementation might never expire a key and would still be compliant. The caveat now recommends to implement your own expiry mechanism if you can't afford stale data, which isn't really ergonomic IMO. I imagine that many KV users who look for the expiration feature also want their keys to be expired.

Three related ideas:

1. Would it be possible to add a boolean option to the get and/or list methods; like guaranteeExpiry or expireKeys (default false), that guarantees that expired keys will not be returned? I guess this would also imply strong consistency, and not be compatible with eventual consistency.
2. The expiry information is not part of the value metadata now (AFAIK). Could another expirationtime timestamp (in ms) be added next to versionstamp? This way it would be easier to implement our own expiration checking if (1) is not available.
3. I think this is an important caveat, and it might be worthwhile to draw more attention to it. Many people don't read full docs pages, unfortunately (guilty as charged), and the caveat is now a bit lost/hidden at the end of the manual page (https://docs.deno.com/deploy/kv/manual/key_expiration/ ). For example, moving the caveat to a yellow warning box on top, immediately after the example in the introduction, would draw more attention to it. In the style of this blue note: