test: add tests for arrow function fallback behavior #1063
Conversation
yanxue-22
changed the title
yanxue-22
force-pushed
the
DX-2214-Test-Fix-For-Unknown-identifer-codec
branch
6 times, most recently
from
bf9c320 to
465569a
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR adds a test to validate the fix for arrow function parameter parsing fallback behavior. The test ensures that when the parser fails to inline arrow function bodies with parameters, it correctly falls back to using predefined custom codec definitions instead of throwing an "Unknown identifier" error.
Key changes:
- Adds a new test case that validates the parser's fallback mechanism for arrow functions with parameters
- Test creates a realistic scenario with
arrayFromArrayOrSingle(NonEmptyString)to verify the fallback works correctly
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
starfy84
left a comment
starfy84
left a comment
There was a problem hiding this comment.
@yanxue-22 I think copilot's suggestions broke your PR 😆
The suggestions are correct though. Using required doesn't give TestProject the correct types (it gets typed as any).
The test looks good! But I was wondering if the original fix was correct in the first place 🤔 . Or maybe there's a flaw with the original implementation. The Why the Fix Works section isn't really convincing me too much as to why exactly we need the fallback in the first place. We can go over this during collab!
| const knownImports = { | ||
| '.': { | ||
| arrayFromArrayOrSingle: (_: any, innerSchema: any) => | ||
| E.right({ type: 'array', items: innerSchema }), | ||
| }, | ||
| }; |
There was a problem hiding this comment.
Looks like the type of knownImports doesn't align with the KnownImports type definition
There was a problem hiding this comment.
Agreed. Not entirely confident either now that you point it out - will join collab hours tomorrow!
yanxue-22
force-pushed
the
DX-2214-Test-Fix-For-Unknown-identifer-codec
branch
3 times, most recently
from
831c67f to
9fcd9b9
Compare
Check if parseFunctionBody() succeeded before returning, allowing parser to use custom codec definitions when function contains parameter references. Ticket: DX-2418
yanxue-22
force-pushed
the
DX-2214-Test-Fix-For-Unknown-identifer-codec
branch
from
9fcd9b9 to
08ab81b
Compare
| const hasNoParameters = calleeInit.params.length === 0; | ||
| if (hasNoParameters) { | ||
| return parseFunctionBody(project, calleeSourceFile, calleeInit); |
There was a problem hiding this comment.
If I'm understanding this correctly; parseFunctionBody fails on functions with parameters. The fix is to only parse the function body if it has no parameters.
My question:
Is the fact that parseFunctionBody fails on arrow functions with parameters a flaw with the way we defined parseFunctionBody? Or is this intended behaviour?
There was a problem hiding this comment.
f I'm understanding this correctly;
parseFunctionBodyfails on functions with parameters. The fix is to only parse the function body if it has no parameters.
Correct
There was a problem hiding this comment.
Is the fact that
parseFunctionBodyfails on arrow functions with parameters a flaw with the way we definedparseFunctionBody? Or is this intended behaviour?
I think it is intended that parseFunctionBody only handles zero-parameter functions, since that was the case that surfaced the need for function. Arrow functions with parameters are left to be handled via custom codec definitions in knownImports, which I believe manually defines the schema transformation.
Ticket: DX-2214
This PR attempts to validate this following fix, which resolved an issue introduced by this Regression Commit.
Original Problem
The system encountered an error when parsing certain Arrow Functions with parameters (e.g.,
(codec) => t.array(codec)), specifically:Error: Error when parsing AdminUpdateShardKeyApiSpec: Unknown identifier codec.What is
parseFunctionBodyparseFunctionBodyextracts and parses the body of an arrow function:() => t.string, it parses the expressiont.string() => { return t.string; }, it finds the return statement and parses its argumentThe problem is that when parsing the body, any function parameters (like
codec) are not in the symbol table (codecIdentifierhas not been called yet)The Fix
We only try inlining for arrow functions without parameters (that would have custom codecs).
Testing
arrayFromArrayOrSingle(NonEmptyString)correctly resolves to{ type: 'array', items: {...} }using the custom codecrefinstead of throwing"Unknown identifier codec"