Add maximum recursion depth for object path finding

Summary

Calculating object paths for typing is computationally expensive. We use this technique for step.waitForEvent()'s match option and some parts of function configuration, such as cancelOn.

Depending on the sheer size of some events, these comparisons can generate tens of thousands of valid strings, resulting in a lot of recursion and processing by the language server. In unlucky cases, the compiler appears to hang indefinitely as it recurses, taking an unreasonable amount of time to hit the built-in depth of 1,000.

This change ensures we never try to go as deep, limiting our recursion to 8. This means that, when validating the match property, we will find and allow...

"data.foo.bar.baz.qux.quux.corge.grault.garply"

...but not...

"data.foo.bar.baz.qux.quux.corge.grault.garply.waldo"

Use of the latter can still be specified using the if property:

"event.data.foo.bar.baz.qux.quux.corge.grault.garply.waldo == async.data.foo.bar.baz.qux.quux.corge.grault.garply.waldo"

Note that these changes only address one facet of the complexity of calculating the object paths here; sheer volume of events can still overwhelm the compiler. In the future, we will remove this field and typing in favour of CEL expressions with better DX.

Checklist

[ ] ~~Added a docs PR that references this PR~~ N/A
[ ] ~Added unit/integration tests~ N/A Existing tests cover
[x] Added changesets if applicable

inngest / inngest-js

Add maximum recursion depth for object path finding #615

Summary

Checklist

🦋 Changeset detected