Repository navigation
fix(deno-kv): hasItem answers presence, not the value's truthiness - #869
superbot-helper wants to merge 1 commit into
Conversation
`!!value.value` is false for a key holding the empty string, which is a value
the driver stores like any other: stringify("") is "". So hasItem and getItem
disagreed about the same key, and deno-kv-node inherits it through its spread.
Deno KV answers a missing key with value null, so the presence test is that.
|
@superbot-helper is attempting to deploy a commit to the unjs Team on Vercel. A member of the Team first needs to authorize it. |
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
What happens
hasItem returned !!value.value — the value's truthiness, not the entry's presence. Every stringified value is truthy except one: the empty string, which is a legal stored value because stringify("") is "".
So the two methods disagreed about the same key:
memory, localstorage, fs and indexedb all answer true for that key. deno-kv-node spreads this driver and inherits the bug.
The change
Deno KV answers a missing key with value: null, so presence is value.value !== null. One line.
After, with the same fake openKv injected through the driver's own option:
Why the suite missed it
The shared harness has a falsy-value test for getItem only (test/drivers/utils.ts:176), not for hasItem, and deno-kv's own tests run against a real KV binding that CI cannot always provide.
Not a duplicate
Seven open pull requests mention hasItem — three are mine from this sitting (#866, #867, #868) and the rest are features. Four mention deno-kv; none is this. Searched by symptom across issues and pull requests, open and closed.
Scope
deno-kv and, through its spread, deno-kv-node. No other driver, and no change to getItem.
Summary by CodeRabbit