The Node SDK accepts context fields of any type and internally assumes they are strings without converting them. This means that e.g. the IN operator returns false for non-string values when we would otherwise expect it to return true.
Taking a strategy like test IN 1337 as an example:
{ test: '1337' } returns ✅ TRUE - Both are strings so they satisfy ===
{ test: 1337 } returns ❌ FALSE - One is a string, the other is a number, so they don't satisfy ===
This change makes it so we convert context values to string, using .toString() in our context value resolver. The result is that both of these examples now return ✅ TRUE.
I think this is a positive change overall since it should not break any existing intended behavior and internally we're assuming the context values are strings anyways, even if they aren't.
The Node SDK accepts context fields of any type and internally assumes they are strings without converting them. This means that e.g. the
INoperator returnsfalsefor non-string values when we would otherwise expect it to returntrue.Taking a strategy like
test IN 1337as an example:{ test: '1337' }returns ✅ TRUE - Both are strings so they satisfy==={ test: 1337 }returns ❌ FALSE - One is a string, the other is a number, so they don't satisfy===This change makes it so we convert context values to string, using
.toString()in our context value resolver. The result is that both of these examples now return ✅ TRUE.I think this is a positive change overall since it should not break any existing intended behavior and internally we're assuming the context values are strings anyways, even if they aren't.