feat(js): add init data support to client and express handler#5247
feat(js): add init data support to client and express handler#5247pavelgj wants to merge 26 commits intopj/bidi-actionsfrom
Conversation
…ectly into `ActionParams` and removing the separate `BidiActionParams` interface.
…action execution.
…eamline run/stream types
… lifecycle management with proper cleanup
…alues and add supporting test case
Add support for an `init` parameter in the action run pipeline to establish long-running session states. This propagates the parameter through the reflection server (v1 and v2), API schemas, and includes tests for both streaming and non-streaming action invocations.
Add `init` parameter to `streamFlow` and `runFlow` client functions and propagate it through the Express handler to action execution. This allows passing initialization data (defined via `initSchema`) from clients to flows and actions. Includes tests and documentation.
pavelgj
changed the title
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces support for initialization data (init) across Genkit clients and server-side handlers, including Express, Fetch, and Next.js. The changes allow passing init data through runFlow and streamFlow, which is then validated against the action's initSchema on the server. The PR also includes updated documentation and new test cases for each plugin. Feedback was provided to enhance type safety in the Express handler by using the generic context type C instead of any in the Action definition.
| Init extends z.ZodTypeAny = z.ZodTypeAny, | ||
| >( | ||
| action: Action<I, O, S>, | ||
| action: Action<I, O, S, any, Init>, |
There was a problem hiding this comment.
The Action type parameter for context should use the generic C instead of any. This ensures that the action is compatible with the context provided by the contextProvider. Using any here bypasses type checking for context compatibility, which could lead to runtime errors if the action expects a specific context type that the provider does not supply. Stricter type validation is preferred in this repository to ensure consistency and safety.
| action: Action<I, O, S, any, Init>, | |
| action: Action<I, O, S, C, Init>, |
References
- Stricter validation is preferable to maintain consistency and prevent runtime errors.
1 participant
Parent PR: #4288