✨ Add Webhook block #1815
✨ Add Webhook block #1815
Conversation
Closes #1531
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the WalkthroughThe pull request introduces several modifications primarily focused on transitioning from webhook-related functionality to HTTP request handling within the application. Key changes include updates to the Changes
Assessment against linked issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 45
🧹 Outside diff range and nitpick comments (69)
packages/blocks/logic/src/constants.ts (1)
10-10: Approved with a minor suggestion for consistency.The addition of the
WEBHOOKenum member aligns well with the PR objectives to add a webhook block. However, for consistency with other enum members, consider capitalizing the value:- WEBHOOK = "webhook", + WEBHOOK = "Webhook",This change would maintain the naming convention used throughout the enum.
packages/blocks/integrations/src/constants.ts (1)
Line range hint
1-12: Add documentation for the IntegrationBlockType enumThe
IntegrationBlockTypeenum lacks documentation explaining its purpose and the significance of each member. Consider adding a comment above the enum to describe its role in the system and any important details about its usage.Additionally, it would be helpful to document the reason for changing
WEBHOOKtoHTTP_REQUEST. This context can be valuable for future maintenance and understanding the evolution of the codebase.Here's a suggested documentation format:
/** * Represents the types of integration blocks available in the system. * Each enum member corresponds to a specific integration type and is associated with a display name. * * Note: The HTTP_REQUEST member (formerly WEBHOOK) represents a generic HTTP request integration, * which includes but is not limited to webhook functionality. */ export enum IntegrationBlockType { // ... (enum members) }packages/bot-engine/src/blocks/logic/webhook/executeWebhookBlock.ts (2)
4-14: LGTM: Function implementation is concise and appropriate, with room for potential improvements.The
executeWebhookBlockfunction is well-structured and correctly implements the basic webhook execution logic. It properly uses the inputblockto set theoutgoingEdgeIdand creates a client-side action to listen for the webhook.Suggestions for potential improvements:
- Consider adding input validation for the
blockparameter to ensure it has the expected properties.- You might want to add error handling to manage cases where the webhook execution fails.
- The function could be more flexible by allowing multiple client-side actions if needed in the future.
Here's an example of how you could implement these suggestions:
export const executeWebhookBlock = ( block: WebhookBlock ): ExecuteLogicResponse => { if (!block || typeof block.outgoingEdgeId !== 'string') { throw new Error('Invalid WebhookBlock: missing or invalid outgoingEdgeId'); } return { outgoingEdgeId: block.outgoingEdgeId, clientSideActions: [ { type: "listenForWebhook", expectsDedicatedReply: true, }, ], }; };This implementation includes basic input validation and throws an error if the input is invalid. You could expand on this based on your specific requirements.
1-14: Summary: Implementation successfully adds webhook block functionality.This new file successfully implements the webhook block execution, aligning with the PR objective of adding a webhook block to the system. The code is well-structured, uses TypeScript effectively, and provides the basic functionality required for webhook integration.
The implementation allows for webhook listening as a client-side action, which should integrate well with the existing Wait block, addressing the linked issue #1531. However, to fully meet the objectives, ensure that:
- The Wait block can effectively utilize this webhook functionality.
- The user interface appropriately exposes this new webhook option within the Wait block settings.
Consider implementing the suggested improvements to enhance the robustness and flexibility of this feature. Overall, this implementation is a solid foundation for the new webhook functionality.
To fully realize the potential of this new webhook block:
- Ensure proper integration with the Wait block logic.
- Implement appropriate error handling and timeout mechanisms for webhook responses.
- Consider adding configuration options for webhook timeouts and retry logic.
- Develop comprehensive documentation for users on how to utilize this new webhook functionality within their workflows.
apps/builder/src/features/blocks/integrations/httpRequest/api/router.ts (2)
7-12: LGTM: Router configuration is well-structured.The
httpRequestRouteris correctly configured with appropriate methods for HTTP request operations. The structure is clean and follows best practices.Consider adding a brief comment describing the purpose of each method in the router configuration. This would enhance code readability and maintainability. For example:
export const httpRequestRouter = router({ // Retrieves a list of HTTP request blocks listHttpRequestBlocks, // Generates an example of the expected result getResultExample, // Handles subscription to HTTP requests subscribeHttpRequest, // Handles unsubscription from HTTP requests unsubscribeHttpRequest, });
1-12: Implementation aligns well with PR objectives.The introduction of the
httpRequestRouterwith methods for listing, subscribing, and unsubscribing to HTTP requests provides a solid foundation for the webhook block functionality mentioned in the PR objectives. This implementation should facilitate the integration of webhooks into the Wait block as requested in issue #1531.As you continue to develop this feature:
- Ensure proper error handling is implemented in each of the imported functions.
- Consider adding authentication and rate limiting to protect the webhook endpoints.
- Implement logging for each HTTP request operation to aid in debugging and monitoring.
- Plan for scalability, as webhook operations can potentially generate high volumes of traffic.
packages/bot-engine/src/logs/filterPotentiallySensitiveLogs.ts (1)
Line range hint
6-21: LGTM. Consider adding a comment for clarity.The function
filterPotentiallySensitiveLogsremains unchanged and continues to serve its purpose of filtering out potentially sensitive logs. This is good practice for maintaining security.For improved clarity, consider adding a brief comment explaining the function's purpose and why these specific log descriptions are considered potentially sensitive. For example:
// Filter out logs that may contain sensitive information related to webhooks and emails export const filterPotentiallySensitiveLogs = (log: { // ... rest of the functionpackages/blocks/integrations/src/httpRequest/constants.ts (1)
Line range hint
19-23: Approved: Consistent naming and type safetyThe renaming of
defaultWebhookBlockOptionstodefaultHttpRequestBlockOptionsis appropriate and consistent with the previous change. It accurately represents the purpose of the constant for HTTP request blocks.The use of
as const satisfies HttpRequestBlockV6["options"]is excellent for ensuring type safety and maintaining the correct structure for the options.Consider grouping related constants together for better code organization. You could move
defaultTimeoutandmaxTimeoutnext to the other HTTP request-related constants for improved readability.apps/builder/src/features/blocks/logic/webhook/components/WebhookIcon.tsx (1)
5-15: LGTM with a minor suggestion: Icon implementation is well-structured and follows best practices.The implementation of the
WebhookIconcomponent is solid:
- It correctly uses Chakra UI's
Iconcomponent.- The
useColorModeValuehook ensures proper theming support.- Spreading
featherIconsBasePropsand additional props allows for flexibility.- The SVG paths appropriately define a webhook-like icon.
Consider extracting the SVG paths into a constant or a separate file if this icon is used in multiple places. This would improve maintainability and reduce duplication if the icon is used elsewhere.
const WEBHOOK_ICON_PATHS = [ "M18 16.98h-5.99c-1.1 0-1.95.94-2.48 1.9A4 4 0 0 1 2 17c.01-.7.2-1.4.57-2", "m6 17 3.13-5.78c.53-.97.1-2.18-.5-3.1a4 4 0 1 1 6.89-4.06", "m12 6 3.13 5.73C15.66 12.7 16.9 13 18 13a4 4 0 0 1 0 8" ]; // Then in the component: {WEBHOOK_ICON_PATHS.map((d, i) => ( <path key={i} d={d} /> ))}packages/embeds/js/src/features/blocks/integrations/httpRequest/executeHttpRequest.ts (2)
Line range hint
6-22: Update error message for consistency.The function body remains consistent with the previous implementation, which is good. However, there's a minor inconsistency in the error message.
Consider updating the error message for consistency:
- data: "An error occured while executing the webhook on the client", + data: "An error occurred while executing the HTTP request on the client",Also, note the typo correction from "occured" to "occurred".
Line range hint
1-22: Summary: Consistent refactoring towards general HTTP request handling.The changes in this file represent a shift from a webhook-specific approach to a more general HTTP request handling approach. This refactoring improves code clarity and flexibility. The core logic remains unchanged, ensuring consistent behavior.
Key points:
- Import path updated to reflect the new structure.
- Function and parameter names changed for clarity.
- Function body remains consistent, with a minor suggestion for error message update.
These changes likely impact other parts of the codebase. Ensure that all references to the old function name and import path are updated accordingly.
Consider reviewing the entire codebase for any remaining "webhook" terminology that might need to be updated for consistency with this new approach. This could include variable names, comments, documentation, and potentially even user-facing text if applicable.
packages/blocks/integrations/src/zapier/schema.ts (1)
Line range hint
1-30: Approve overall structure with a suggestion for documentation.The overall structure of the file is well-organized and follows good practices:
- Use of zod for schema definition ensures runtime type checking.
- Versioning of schemas (v5 and v6) suggests good backwards compatibility practices.
- Proper use of TypeScript for type definitions.
Consider adding JSDoc comments to the main exported types and schemas for better documentation. For example:
/** * Represents the schema for a Zapier integration block. * @typedef {z.infer<typeof zapierBlockSchema>} ZapierBlock */ export type ZapierBlock = z.infer<typeof zapierBlockSchema>;This would improve the developer experience when working with these types in other parts of the codebase.
packages/blocks/logic/src/webhook/schema.ts (2)
5-15: Consider renamingwaitOptionsSchemafor clarity.The schema structure is well-defined and provides good flexibility with optional fields. However, the name
waitOptionsSchemamight be confusing in the context of a webhook. Consider renaming it to something more specific, such aswebhookResponseMappingSchema.Here's a suggested change:
-export const waitOptionsSchema = z.object({ +export const webhookResponseMappingSchema = z.object({ responseVariableMapping: z .array( z.object({ id: z.string(), variableId: z.string().optional(), bodyPath: z.string().optional(), }), ) .optional(), });
17-27: LGTM: Well-structured webhook block schema with OpenAPI metadata.The
webhookBlockSchemais well-defined, extending the base schema and including the necessary properties for a webhook block. The OpenAPI metadata is a good addition for documentation purposes.If you decide to rename
waitOptionsSchemaas suggested earlier, don't forget to update its reference here:export const webhookBlockSchema = blockBaseSchema .merge( z.object({ type: z.enum([LogicBlockType.WEBHOOK]), - options: waitOptionsSchema.optional(), + options: webhookResponseMappingSchema.optional(), }), ) .openapi({ title: "Webhook", ref: "webhookLogic", });apps/docs/editor/blocks/inputs/website.mdx (1)
31-31: LGTM! Consider clarifying the context.The update from "Webhook block" to "HTTP request block" improves accuracy and aligns with the PR objectives. Good job on keeping the documentation up-to-date.
However, I have a couple of suggestions:
The file is about Website input, but the content discusses email validation. Consider clarifying the relationship between website input and email validation, or update the content to focus on website URL validation instead.
It might be beneficial to review the entire document to ensure consistency with this change and to verify that all references to validation methods are up-to-date.
Would you like assistance in reviewing the rest of the document or updating the content to focus on website URL validation?
🧰 Tools
🪛 LanguageTool
[style] ~31-~31: Consider a more expressive alternative.
Context: ...k if the email address is valid. To do that, you will have to trigger a [HTTP ...(DO_ACHIEVE)
apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestNodeContent.tsx (1)
Line range hint
1-31: Summary: Changes align well with PR objectivesThe modifications in this file, including the import path update and component renaming, are consistent with the PR objective of adding a webhook block. These changes appear to be part of a larger refactoring effort to support the new feature while maintaining the existing functionality.
The minimal and focused nature of these changes is commendable, as it reduces the risk of introducing unintended side effects. However, it's crucial to ensure that these changes are consistently applied across the entire codebase.
As you continue to implement the webhook block feature:
- Consider adding comprehensive unit tests for the
HttpRequestNodeContentcomponent to ensure its behavior remains correct after these changes.- Update any relevant documentation or comments to reflect the new component name and import path.
- If not already planned, consider creating integration tests that verify the end-to-end functionality of the new webhook block feature.
apps/builder/src/features/blocks/logic/webhook/components/WebhookNodeContent.tsx (2)
12-29: LGTM with a minor suggestion: Component implementation is solid.The WebhookNodeContent component is well-structured and efficiently implemented. It correctly uses the useTypebot hook, handles potential undefined values with optional chaining, and properly filters and maps the responseVariableMapping array.
Consider extracting the filtering and mapping logic into a separate function for improved readability:
const renderVariableMappings = (mappings: WebhookBlock['options']['responseVariableMapping']) => mappings ?.filter((mapping) => isDefined(mapping.variableId)) .map((mapping, idx) => ( <SetVariableLabel key={mapping.variableId! + idx} variables={typebot.variables} variableId={mapping.variableId!} /> )); // Then in the JSX: {typebot && renderVariableMappings(options?.responseVariableMapping)}This change would make the component's render method cleaner and easier to understand at a glance.
1-29: Great implementation of the WebhookNodeContent component.This new component aligns well with the PR objective of adding a webhook block. It provides a clean and efficient way to render webhook node content, including the ability to display variable mappings when available. The implementation is type-safe, follows React best practices, and handles potential edge cases appropriately.
The component contributes to the goal of enhancing the application's webhook functionality, as mentioned in the PR objectives. It provides a user interface element that can be used to represent webhook blocks within the larger system, potentially integrating with the Wait block as per the linked issue #1531.
As the webhook feature develops further, consider the following architectural points:
- Ensure that this component integrates smoothly with the Wait block or any other relevant blocks in the system.
- Plan for potential future expansions of the webhook functionality, such as additional configuration options or more complex response handling.
- Consider creating comprehensive unit tests for this component to ensure its reliability as the codebase evolves.
packages/typebot/src/migrations/migrateTypebotFromV3ToV4.ts (1)
Line range hint
8-10: Approve function signature update and suggest documentation review.The updated function signature with a more specific return type is a good improvement. It enhances type safety and clearly communicates the function's output, particularly the version change to "4".
Consider reviewing and updating any existing documentation for this function to reflect the more specific return type. This will help maintain consistency between the code and its documentation.
If you'd like, I can assist in generating updated documentation for this function. Would you like me to do so?
packages/blocks/logic/src/schema.ts (1)
32-32: LGTM: Webhook block schema added to logicBlockV6Schema.The addition of
webhookBlockSchemato thelogicBlockV6Schemais correct and consistent with the existing structure. This change successfully incorporates the new webhook block into the logic block types for version 6.Consider adding a comment above the
logicBlockV6Schemato document the addition of the webhook block, especially if this is a significant new feature. For example:// V6 schema includes all V5 blocks plus the new webhook block export const logicBlockV6Schema = z.discriminatedUnion("type", [ // ... existing blocks webhookBlockSchema, ]);apps/docs/editor/blocks/logic/webhook.mdx (3)
10-26: Enhance URL parameter explanationsThe Test URLs section is informative, but could benefit from some improvements:
- Consider adding an explanation for obtaining the
{typebotId}and{blockId}parameters.- The
{phone}parameter explanation could be more precise.Consider updating the
{phone}explanation as follows:-Where `{phone}` is your phone number on which you test the bot. For example, if you provided `+33 601 020304`, `{phone}` should be `33601020304`, no spaces, no `+`. +Where `{phone}` is your phone number for testing the bot. It should be in E.164 format without the leading '+'. For example, if your number is `+33 601 020304`, `{phone}` should be `33601020304`.Would you like me to draft an explanation for obtaining the
{typebotId}and{blockId}parameters?
28-36: LGTM: Clear production URL explanationThe Production URL section is well-explained and includes helpful information on obtaining the
{resultId}parameter. The link to the Set variable documentation is particularly useful.As mentioned earlier, consider adding explanations for obtaining the
{typebotId}and{blockId}parameters, which are common to both test and production URLs.
38-40: LGTM: Concise authentication informationThe Authentication section effectively directs users to the necessary documentation for API authentication.
Consider a minor wording improvement for conciseness:
-The Webhook URL needs to be authenticated in order to work. See [API authentication](/api-reference/authentication) for more information. +The Webhook URL requires authentication to function. See [API authentication](/api-reference/authentication) for more information.🧰 Tools
🪛 LanguageTool
[style] ~40-~40: Consider a shorter alternative to avoid wordiness.
Context: ...e Webhook URL needs to be authenticated in order to work. See [API authentication](/api-ref...(IN_ORDER_TO_PREMIUM)
apps/builder/src/features/blocks/integrations/httpRequest/components/ResponseMappingInputs.tsx (1)
Line range hint
8-38: Suggestion: Enhance type safety and prop validationWhile the component looks well-structured, consider the following improvements to enhance type safety and prop validation:
- Use
React.FCtype for the component to ensure better type checking:import React from 'react'; export const DataVariableInputs: React.FC<TableListItemProps<ResponseVariableMapping> & { dataItems: string[] }> = ({ item, onItemChange, dataItems, }) => { // ... component logic };
- Add prop-types for runtime type checking:
import PropTypes from 'prop-types'; DataVariableInputs.propTypes = { item: PropTypes.shape({ bodyPath: PropTypes.string, variableId: PropTypes.string, }).isRequired, onItemChange: PropTypes.func.isRequired, dataItems: PropTypes.arrayOf(PropTypes.string).isRequired, };
- Consider using a custom hook for handling state and callbacks to improve readability and reusability:
const useDataVariableInputs = (item: ResponseVariableMapping, onItemChange: (item: ResponseVariableMapping) => void) => { const handleBodyPathChange = React.useCallback((bodyPath: string) => { onItemChange({ ...item, bodyPath }); }, [item, onItemChange]); const handleVariableChange = React.useCallback((variable?: Variable) => { onItemChange({ ...item, variableId: variable?.id }); }, [item, onItemChange]); return { handleBodyPathChange, handleVariableChange }; };These suggestions can help improve the overall quality and maintainability of the component.
apps/builder/src/features/blocks/integrations/makeCom/components/MakeComSettings.tsx (1)
Line range hint
1-54: LGTM! Consider a minor readability improvement.The
MakeComSettingscomponent is well-structured and correctly implements the Make.com integration settings. It properly uses the importedHttpRequesttype andHttpRequestAdvancedConfigFormcomponent, and the logic remains unchanged after the import path updates.To slightly improve code readability, consider destructuring the
optionsprop in the function parameters:export const MakeComSettings = ({ block: { id: blockId, options }, onOptionsChange, -}: Props) => { +}: Props) => { + const { webhook } = options; const setLocalWebhook = async (newLocalWebhook: HttpRequest) => { onOptionsChange({ ...options, webhook: newLocalWebhook, }); }; - const url = options?.webhook?.url; + const url = webhook?.url; // ... rest of the component };This change would make the code slightly more concise and easier to read, especially when accessing the
webhookproperty multiple times within the component.apps/builder/src/features/blocks/integrations/zapier/components/ZapierSettings.tsx (1)
6-9: Summary of changes and potential impact on the codebaseThe changes in this file are limited to import statements, reflecting a restructuring of the module organization from webhook-related to HTTP request-related namespaces. While these changes don't affect the
ZapierSettingscomponent's logic, they might be part of a larger refactoring effort.Consider the following:
- Ensure that all files using these imports have been updated consistently.
- Update any documentation or contribution guidelines to reflect the new module structure.
- If this is part of a larger refactoring, consider creating a migration guide for other developers working on the project.
To help verify the consistency of these changes across the codebase, you can run the following script:
#!/bin/bash # Description: Check for any remaining imports using old paths # Test 1: Search for imports from the old webhook schema path echo "Checking for old webhook schema imports:" rg --type typescript 'from.*@typebot\.io/blocks-integrations/webhook/schema' # Test 2: Search for imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for old HttpRequestAdvancedConfigForm imports:" rg --type typescript 'from.*\.\.\/\.\.\/webhook\/components\/HttpRequestAdvancedConfigForm'This script will help identify any files that might have been missed during the refactoring process.
apps/viewer/src/pages/api/typebots/[typebotId]/webhookSteps.ts (1)
Line range hint
1-45: Summary: Changes look good, but some clarifications and additional steps are recommended.Overall, the changes to this file look good and seem to align with the PR objective of adding a webhook block. The shift from
isWebhookBlocktoisHttpRequestBlockand the more specific filtering logic are improvements. However, to ensure a smooth integration of these changes, I recommend the following steps:
- Clarify the relationship between these changes and the Wait block mentioned in issue Add Webhook block #1531.
- Add comments to explain the new filtering logic, particularly the check for undefined URLs in associated webhooks.
- Update any relevant documentation to reflect the change from "webhook blocks" to "HTTP request blocks".
- Run the verification script provided earlier to check for any remaining uses of
isWebhookBlockin the codebase and update them if necessary.- Consider adding or updating unit tests to cover the new filtering logic.
These changes might have implications for other parts of the system. It would be beneficial to review and update any other components that interact with webhook or HTTP request blocks to ensure consistency across the entire application.
apps/viewer/src/pages/api/typebots/[typebotId]/webhookBlocks.ts (1)
Line range hint
1-41: Consider renaming the file to reflect new terminology.While the changes in this file are consistent and well-implemented, the filename
webhookBlocks.tsno longer accurately represents its contents. Given the shift from webhook blocks to HTTP request blocks, consider the following suggestions:
- Rename this file to
httpRequestBlocks.tsor a similar appropriate name.- Update any imports or references to this file throughout the project.
- Review and update related documentation to reflect this change in terminology.
To assist with this refactoring, you can use the following script to identify files that may need updates:
#!/bin/bash # Description: Find files referencing the current webhookBlocks.ts file. echo "Files referencing webhookBlocks.ts:" rg --type typescript "webhookBlocks\.ts"This change will improve consistency and make the codebase more intuitive for future development.
packages/bot-engine/src/executeLogic.ts (1)
Line range hint
1-42: Summary: Webhook block implementation looks good, with one item to verify.The changes to implement the webhook block execution are well-structured and consistent with the existing code patterns. The new import and switch case are correctly placed and implemented.
Next steps:
- Verify whether the
stateparameter should be passed toexecuteWebhookBlock.- If necessary, update the function call as suggested in the previous comment.
- Once verified or updated, this implementation should be ready for merging.
Consider adding a unit test for the new webhook case in the
executeLogicfunction to ensure it's correctly handled and to maintain test coverage as the codebase evolves.apps/builder/src/features/blocks/integrations/httpRequest/api/getResultExample.ts (1)
19-20: Approve metadata changes with a minor suggestion.The metadata updates correctly reflect the shift from webhook-specific to more general HTTP request handling, which is consistent with the import changes and the PR objectives.
Consider updating the description to fully reflect the HTTP request focus:
- 'Returns "fake" result for http request block to help you anticipate how the webhook will behave.', + 'Returns "fake" result for http request block to help you anticipate how the request will behave.',This change would maintain consistency throughout the description.
apps/builder/src/features/blocks/integrations/pabbly/components/PabblyConnectSettings.tsx (1)
Line range hint
1-72: Summary: Import refactoring with preserved functionalityThe changes in this file are part of a larger refactoring effort to separate HTTP request functionality from webhook-specific code. The import statements have been updated to reflect this new structure, while the component's logic remains unchanged. This approach maintains backwards compatibility and improves code organization.
To ensure the consistency of these changes across the codebase, please run the verification script provided in the earlier comment.
Consider updating the documentation to reflect these structural changes, especially if there are guidelines for importing and using HTTP request or webhook-related functionality in your project.
packages/bot-engine/src/saveStateToDatabase.ts (2)
47-50: LGTM: updateSession call updated with isReplying stateThe inclusion of
isReplyingin theupdateSessioncall is appropriate and consistent with the type changes. The use of the nullish coalescing operator ensures a default value offalsewhenisReplyingisundefined.For improved clarity, consider using an explicit boolean conversion:
-updateSession({ id, state, isReplying: isReplying ?? false }), +updateSession({ id, state, isReplying: Boolean(isReplying) }),This change makes it clear that
isReplyingis always a boolean value, which might be beneficial for type inference in other parts of the codebase.
55-59: LGTM: createSession call updated with isReplying stateThe inclusion of
isReplyingin thecreateSessioncall is appropriate and consistent with the type changes and theupdateSessioncall. The use of the nullish coalescing operator ensures a default value offalsewhenisReplyingisundefined.For improved clarity and consistency with the previous suggestion, consider using an explicit boolean conversion:
-isReplying: isReplying ?? false, +isReplying: Boolean(isReplying),This change makes it clear that
isReplyingis always a boolean value and maintains consistency with the suggested change in theupdateSessioncall.packages/deprecated/bot-engine/src/features/blocks/integrations/webhook/utils/executeWebhookBlock.ts (1)
Line range hint
11-70: Consider these improvements for better code quality:
Use type narrowing for better type safety:
Instead of using a union type for theblockparameter, consider using type narrowing to handle each block type separately. This can improve type safety and make the code more maintainable.Extract the status code check into a separate function:
The status code check logic can be extracted into a separate function for better readability and reusability.Use optional chaining for safer property access:
When accessing nested properties, consider using optional chaining to prevent potential runtime errors.Here's an example of how you could implement these suggestions:
const isErrorStatusCode = (statusCode: string): boolean => statusCode.startsWith('4') || statusCode.startsWith('5'); const executeWebhook = async ( block: HttpRequestBlock | ZapierBlock | MakeComBlock | PabblyConnectBlock, state: IntegrationState ) => { // ... existing code ... const statusCode = (data as Record<string, string>)?.statusCode?.toString(); const isError = statusCode ? isErrorStatusCode(statusCode) : true; // ... rest of the function ... };These changes would make the code more robust and easier to maintain in the long run.
apps/builder/src/features/blocks/logic/webhook/webhook.spec.ts (3)
10-16: LGTM: Test setup is well-structured. Consider adding a comment for clarity.The test description and initial setup are well-implemented. Importing a pre-configured typebot is an efficient approach for setting up the test environment.
Consider adding a brief comment explaining the purpose of the imported typebot configuration:
await importTypebotInDatabase(getTestAsset("typebots/logic/webhook.json"), { id: typebotId, }); +// This typebot configuration includes a Wait block set up for webhook testing
17-31: LGTM with suggestions: Consider replacing timeout with a more robust waiting mechanism.The test case effectively simulates user interactions and verifies the webhook response. However, there are a couple of areas for improvement:
The
page.waitForTimeout(1000)on line 19 is not ideal for test stability. Consider using Playwright's built-in waiting mechanisms or custom functions that wait for specific conditions.The POST request doesn't include error handling. It's good practice to add assertions for the response status.
Consider applying these changes:
- Replace the timeout with a more robust waiting mechanism:
-await page.waitForTimeout(1000); +await page.waitForResponse(response => response.url().includes('/executeTestWebhook') && response.status() === 200);
- Add error handling for the POST request:
-await request.post( +const response = await request.post( `${env.NEXT_PUBLIC_VIEWER_URL[0]}/api/v1/typebots/${typebotId}/blocks/webhook-block-id/web/executeTestWebhook`, { data: { name: "John", }, headers: { Authorization: `Bearer ${apiToken}`, }, }, ); +expect(response.status()).toBe(200);
32-60: LGTM with suggestions: Consider refactoring repeated code and improving assertions.The test case effectively simulates additional user interactions and verifies the webhook response for multiple triggers. However, there are several areas for improvement:
The
page.waitForTimeout(1000)on line 44 has the same issue as mentioned in the previous comment.The POST request is repeated with minimal changes, which could be refactored into a helper function.
The assertions could be more specific and comprehensive.
Consider applying these changes:
Replace the timeout with a more robust waiting mechanism (as suggested in the previous comment).
Refactor the repeated POST request into a helper function:
async function executeTestWebhook(request, typebotId, name) { const response = await request.post( `${env.NEXT_PUBLIC_VIEWER_URL[0]}/api/v1/typebots/${typebotId}/blocks/webhook-block-id/web/executeTestWebhook`, { data: { name }, headers: { Authorization: `Bearer ${apiToken}` }, } ); expect(response.status()).toBe(200); return response; } // Usage: await executeTestWebhook(request, typebotId, "John");
- Add more specific assertions:
-await expect( - page.getByText(", nice to see you again!", { exact: true }), -).toBeVisible(); -await expect(page.getByText("John")).toBeVisible(); +await expect(page.getByText("John, nice to see you again!")).toBeVisible(); +await expect(page.getByTestId("chat-bubble")).toContainText("John, nice to see you again!");These changes will improve the test's readability, maintainability, and reliability.
packages/bot-engine/src/executeIntegration.ts (1)
35-39: LGTM: Integration types consolidated with HTTP request functionality.The changes effectively consolidate the handling of ZAPIER, MAKE_COM, and PABBLY_CONNECT integration types with the HTTP request functionality. This aligns well with the PR objective of adding a webhook block.
Consider extracting the common options into a constant for improved readability:
const webhookLikeOptions = { disableRequestTimeout: true, startTimeShouldBeUpdated: true, }; return { ...(await executeHttpRequestBlock(state, block, webhookLikeOptions)), ...webhookLikeOptions, };apps/builder/src/features/blocks/integrations/httpRequest/api/unsubscribeHttpRequest.ts (2)
60-60: LGTM! Consider documenting the version check.The changes to the conditional logic and block update process are consistent with the refactoring. The version check on line 60 suggests backward compatibility.
Consider adding a comment explaining the significance of
typebot.version === "6"for future maintainability.Also applies to: 62-62, 66-66
89-89: LGTM! Consider clarifying block structure variations.The database update logic has been correctly adjusted to work with the new
httpRequestBlockvariable.The condition
"webhookId" in httpRequestBlocksuggests that there might be different block structures in use. Consider adding a comment or type guard to clarify when this property is expected to be present.Also applies to: 91-91
packages/embeds/js/src/utils/executeClientSideActions.ts (1)
82-86: LGTM with a minor suggestion for consistency.The new conditions for HTTP requests and webhook listening are well-implemented and integrate smoothly with the existing function structure. However, for better consistency with other conditions, consider refactoring the
listenForWebhookcheck to match the pattern used elsewhere in the function.Consider applying this change for consistency:
- if (clientSideAction.type === "listenForWebhook") { - return listenForWebhook({ - sessionId: context.sessionId, - resultId: context.resultId, - }); - } + if ("listenForWebhook" in clientSideAction) { + return listenForWebhook({ + sessionId: context.sessionId, + resultId: context.resultId, + }); + }This change would make the
listenForWebhookcondition consistent with other conditions in the function, improving readability and maintainability.Also applies to: 97-102
apps/docs/editor/blocks/integrations/http-request.mdx (2)
62-62: Image path updates are good, but consider updating alt text.The image path updates on lines 62 and 70 are consistent with previous changes and maintain the document's focus on HTTP requests. However, the alt text on line 85 still refers to "Simple Webhook POST", which is inconsistent with the shift to HTTP request terminology.
Consider updating the alt text on line 85 to "Simple HTTP POST" or a similar phrase that aligns with the HTTP request focus of the document.
Also applies to: 70-70, 85-85
Line range hint
1-105: Documentation updates align well with HTTP request focus.The changes in this file successfully update the documentation to reflect a focus on HTTP requests rather than webhooks. The image path updates and content refinements improve consistency and clarity. These changes support the PR objectives by providing updated documentation for HTTP request capabilities, which are closely related to the new webhook feature being implemented.
Some suggestions for further improvement:
- Consider reviewing the entire document to ensure all references to "webhook" have been updated to "HTTP request" where appropriate.
- Update the alt text for images to consistently use HTTP request terminology.
- If there are any specific differences or relationships between webhooks and HTTP requests in the context of this feature, consider adding a brief explanation to clarify for users.
Overall, these changes enhance the documentation and support the new feature implementation.
apps/builder/src/features/editor/components/BlockLabel.tsx (2)
Line range hint
71-80: Type safety improvement and new WEBHOOK entry addedThe return type change to
{ [key in LogicBlockType]: string }is consistent with previous improvements, enhancing type safety.The addition of the WEBHOOK entry is noted. However, the label is currently hardcoded in English:
[LogicBlockType.WEBHOOK]: "Webhook",This approach may not be consistent with the internationalization strategy used for other labels.
Consider using the translation function for the WEBHOOK label to maintain consistency:
[LogicBlockType.WEBHOOK]: t("editor.sidebarBlock.webhook.label"),Don't forget to add the corresponding translation key to your localization files.
Line range hint
1-99: Summary of changes and recommendationsThe changes in this file primarily focus on improving type safety for block label functions and introducing new block types (WEBHOOK and HTTP_REQUEST). These modifications enhance the robustness of the type system and expand the functionality of the application.
Key points to address:
- Ensure consistency in using the translation function (t) for all labels, including the newly added WEBHOOK and HTTP_REQUEST labels.
- Verify that the replacement of WEBHOOK with HTTP_REQUEST in the IntegrationBlockType is reflected consistently across the codebase.
- Update localization files with new translation keys for WEBHOOK and HTTP_REQUEST labels.
These changes align well with the PR objective of adding a webhook block and enhancing the Wait block with a webhook option. However, ensure that all related components and documentation are updated to reflect these new features.
packages/bot-engine/src/schemas/clientSideAction.ts (1)
118-124: LGTM: HTTP request action updated correctly.The changes from "webhookToExecute" to "httpRequestToExecute" broaden the scope of the action, providing more flexibility for different types of HTTP requests. The OpenAPI reference and title have been consistently updated.
Consider adding a comment explaining the rationale behind this change, especially if it affects existing implementations or documentation. For example:
// Changed from webhookToExecute to httpRequestToExecute to support a wider range of HTTP requests beyond just webhookspackages/whatsapp/src/schemas.ts (1)
145-152: LGTM! Consider enhancing the webhook schema structure.The addition of the webhook schema to the
incomingMessageSchemais well-structured and consistent with the existing code. It successfully implements the webhook option as per the PR objectives.However, consider the following suggestions to enhance the webhook schema:
The
datafield is currently a generic string. If possible, consider defining a more structured schema for the webhook data to ensure consistency and ease of use.You might want to add optional fields that are commonly used in webhooks, such as
idorevent_type. This could provide more context and flexibility for webhook handling.If specific data formats or structures are expected in the
datafield, consider adding validation or parsing logic to ensure data integrity.Here's a potential enhancement to the webhook schema:
z.object({ from: z.string(), type: z.literal("webhook"), webhook: z.object({ id: z.string().optional(), event_type: z.string().optional(), data: z.union([z.string(), z.record(z.unknown())]), }), timestamp: z.string(), }),This structure allows for more detailed webhook information while maintaining backwards compatibility.
packages/blocks/core/src/helpers.ts (1)
Line range hint
1-124: Summary of changes and potential impactThe changes in this file consistently reflect a shift from webhook-specific terminology to more general HTTP request terminology. This includes updating an import statement, renaming a function, and modifying a type check. These changes appear to be part of a larger refactoring effort to generalize webhook functionality to HTTP requests.
While the changes in this file are coherent and well-implemented, it's important to consider their potential impact on the broader codebase. Other files that interact with these helpers or use similar terminology may need to be updated to maintain consistency.
To ensure a smooth transition, consider the following steps:
- Review and update any documentation that references webhooks to reflect the new HTTP request terminology.
- Check for any configuration files or environment variables that may reference webhooks and update them if necessary.
- Review the user interface and any user-facing text to ensure consistency with the new terminology.
- Update any tests that specifically target webhook functionality to use the new HTTP request terminology and functionality.
These steps will help maintain consistency across the entire project and minimize potential confusion for developers and users alike.
apps/builder/src/lib/theme.ts (1)
192-220: LGTM: Tabs component configuration is well-structured.The Tabs component configuration is well-implemented using Chakra UI's multi-style config pattern. It properly handles both light and dark color modes and provides consistent styling for the tablist, tab, and tabpanel elements.
Consider adding
aria-selectedstyles to improve accessibility:tab: { // ... existing styles ... _selected: { bg: colorMode === "dark" ? "gray.800" : "gray.100", + aria: { + selected: { + border: "2px solid", + borderColor: colorMode === "dark" ? "blue.400" : "blue.500", + }, + }, }, // ... remaining styles ... },This change will provide a visual indicator for the selected tab, enhancing the user experience for both mouse and keyboard users.
apps/builder/src/features/editor/components/BlockIcon.tsx (1)
102-103: LGTM: New case for LogicBlockType.WEBHOOKThe new case for
LogicBlockType.WEBHOOKis correctly implemented and aligns with the PR objective of adding a webhook block.For consistency with other logic block types, consider adding a color prop:
- return <WebhookIcon {...props} />; + return <WebhookIcon color={purple} {...props} />;apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx (1)
135-136: LGTM: Updated case for HTTP request block type.The case for
IntegrationBlockType.HTTP_REQUESTnow correctly renders theHttpRequestNodeContentcomponent. This change aligns with the PR objectives and the removal of the old webhook case.Consider passing only the necessary props to
HttpRequestNodeContentinstead of the entire block object. This would improve encapsulation and reduce the risk of unintended side effects. For example:return <HttpRequestNodeContent options={block.options} />;This suggestion assumes that only
optionsare needed. Adjust according to the actual requirements ofHttpRequestNodeContent.apps/builder/src/features/editor/components/BlocksSideBar.tsx (2)
134-144: LGTM: Conditional logic added for WEBHOOK block type.The changes to
filteredLogicBlockTypessuccessfully implement the conditional inclusion of theWEBHOOKblock type based on theNEXT_PUBLIC_PARTYKIT_HOSTenvironment variable. This aligns with the PR objective of adding a webhook block.Suggestion for improved readability:
Consider extracting the webhook condition into a separate variable for clarity:
const isWebhookEnabled = isDefined(env.NEXT_PUBLIC_PARTYKIT_HOST); const filteredLogicBlockTypes = Object.values(LogicBlockType) .filter((type) => type !== LogicBlockType.WEBHOOK || isWebhookEnabled) .filter((type) => getLogicBlockLabel(t)[type].toLowerCase().includes(searchInput.toLowerCase()) );This change would make the logic more explicit and easier to understand at a glance.
Line range hint
1-285: Summary: Webhook block conditionally added based on environment variable.The changes in this file successfully implement the conditional inclusion of the WEBHOOK block type in the
BlocksSideBarcomponent. This aligns with the PR objective of adding a webhook block to the system. The implementation uses environment variables to control the feature's availability, which is a good practice for feature toggling.The changes are minimal and focused, maintaining the existing functionality while adding the new feature. The code remains clean and consistent with the rest of the component.
Consider documenting the
NEXT_PUBLIC_PARTYKIT_HOSTenvironment variable in the project's configuration or README file to ensure other developers are aware of its significance in enabling the webhook feature.packages/embeds/js/src/components/ConversationContainer/ConversationContainer.tsx (2)
287-287: LGTM! Consider adding a comment for clarity.The addition of
resultIdto the context object passed toexecuteClientSideActionis a good enhancement. It provides more context for client-side actions, which could be particularly useful for the new webhook block functionality.Consider adding a brief comment explaining the purpose of
resultIdto improve code clarity:context: { apiHost: props.context.apiHost, sessionId: props.initialChatReply.sessionId, + // Unique identifier for the chat result, used in webhook calls resultId: props.initialChatReply.resultId, },
Line range hint
389-402: LGTM! Consider adding error handling for unknown input types.The
convertSubmitContentToMessagefunction is a good addition that cleanly handles the conversion of different input types to theMessagetype. This separation of concerns improves code organization and maintainability.Consider adding error handling for unknown input types to make the function more robust:
const convertSubmitContentToMessage = ( answer: InputSubmitContent | undefined, ): Message | undefined => { if (!answer) return; if (answer.type === "text") return { type: "text", text: answer.value, attachedFileUrls: answer.attachments?.map((attachment) => attachment.url), }; if (answer.type === "recording") return { type: "audio", url: answer.url }; + // Handle unknown input types + console.warn(`Unknown input type: ${answer.type}`); + return undefined; };packages/bot-engine/src/blocks/integrations/httpRequest/saveDataInResponseVariableMapping.ts (1)
46-51: Enhance log descriptions with status codes for better contextIncluding the
statusCodein the log descriptions can provide more insight during debugging and monitoring.Apply this diff to include the
statusCodein the log messages:description: `HTTP request returned error`, +details: { + statusCode: response.statusCode, + data: response.data, +},For the success case:
description: `HTTP request executed successfully!`, +details: { + statusCode: response.statusCode, + data: response.data, +},apps/builder/src/features/blocks/integrations/httpRequest/api/subscribeHttpRequest.ts (2)
18-19: Maintain consistent capitalization in OpenAPI metadataIn lines 18-19, to ensure consistency, consider capitalizing "HTTP Request" uniformly in the
summaryandtags.Apply this diff to adjust the capitalization:
- summary: "Subscribe to HTTP request block", + summary: "Subscribe to HTTP Request block", - tags: ["HTTP request"], + tags: ["HTTP Request"],
58-58: Ensure consistent naming in error messagesAt line 58, consider adjusting the error message for consistent capitalization:
Apply this change:
- message: "HttpRequest block not found", + message: "HTTP Request block not found",apps/viewer/src/pages/api/v1/typebots/[typebotId]/blocks/[blockId]/results/[resultId]/executeWebhook.ts (2)
37-37: Avoid hardcoding version numbersUsing a hardcoded version number for
typebot.versionmay lead to maintenance challenges in the future. Consider defining a constant or configuration setting for the supported version.For example:
+ const SUPPORTED_VERSION = "6"; if (typebot.version !== "6") return badRequest(res);Then update the condition:
- if (typebot.version !== "6") return badRequest(res); + if (typebot.version !== SUPPORTED_VERSION) return badRequest(res);
74-75: Streamline JSON parsing and stringificationThe current logic for handling
req.bodycould be simplified to enhance readability.Apply this diff to simplify:
- typeof req.body === "string" - ? JSON.stringify({ data: JSON.parse(req.body) }) - : JSON.stringify({ data: req.body }, null, 2), + const requestData = typeof req.body === "string" ? JSON.parse(req.body) : req.body; + JSON.stringify({ data: requestData }, null, 2),apps/builder/src/pages/api/typebots/[typebotId]/blocks/[blockId]/testHttpRequest.ts (1)
Line range hint
42-58: Rename variables and error messages from 'webhook' to 'httpRequest' for consistencyThe code still uses variable names like
webhookIdandwebhook, and error messages referring to "webhook". Since we're now working with HTTP requests, consider renaming these variables and updating error messages accordingly for clarity and consistency.Apply the following changes:
- Rename
webhookIdtohttpRequestId.- Rename
webhooktohttpRequest.- Update any related error messages.
Here's an example diff:
- const webhookId = "webhookId" in block ? block.webhookId : undefined; - const webhook = - block.options?.webhook ?? - typebot.webhooks.find((w) => { - if ("id" in w) return w.id === webhookId; + const httpRequestId = "httpRequestId" in block ? block.httpRequestId : undefined; + const httpRequest = + block.options?.httpRequest ?? + typebot.httpRequests.find((req) => { + if ("id" in req) return req.id === httpRequestId; return false; }); - if (!webhook) + if (!httpRequest) return res .status(404) - .send({ statusCode: 404, data: { message: `Couldn't find webhook` } }); + .send({ statusCode: 404, data: { message: `Couldn't find HTTP request` } });packages/embeds/js/src/queries/startChatQuery.ts (1)
135-139: Standardize Capitalization of Status MessagesCurrently, the status messages use inconsistent capitalization ("fail" and "Success"). For clarity and consistency, consider standardizing the capitalization.
Option 1: Capitalize both messages:
-message: stripeRedirectStatus === "failed" ? "fail" : "Success", +message: stripeRedirectStatus === "failed" ? "Fail" : "Success",Option 2: Use lowercase for both messages:
-message: stripeRedirectStatus === "failed" ? "fail" : "Success", +message: stripeRedirectStatus === "failed" ? "fail" : "success",Choose a consistent style for status messages to improve readability.
apps/builder/src/features/blocks/logic/webhook/components/WebhookSettings.tsx (1)
70-72: Enhance error handling in WebSocketonErrorhandlerCurrently, the
onErrorhandler logs the error to the console usingconsole.log. This might not provide sufficient visibility into issues that users might experience with the WebSocket connection. Consider enhancing the error handling by usingconsole.errorfor better error logging and providing user feedback, such as displaying a notification or updating the UI to reflect the connection issue.Apply this diff to improve error handling:
onError(e) { - console.log("error", e); + console.error("WebSocket error:", e); + // Optionally, update the UI or notify the user about the error },apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestAdvancedConfigForm.tsx (2)
123-123: Simplify default value assignment forisCustomBodyYou can destructure
isCustomBodydirectly fromoptionswith a default value to simplify the code.Suggested refactor:
- const isCustomBody = - options?.isCustomBody ?? defaultHttpRequestBlockOptions.isCustomBody; + const { isCustomBody = defaultHttpRequestBlockOptions.isCustomBody } = options ?? {};
148-149: Avoid unnecessary type castingIn the
currentItemprop ofDropdownList, the casting toHttpMethodmay be unnecessary if the types align correctly. Ensure thathttpRequest?.methodanddefaultHttpRequestAttributes.methodare of typeHttpMethod.Suggested fix:
currentItem={ - (httpRequest?.method ?? defaultHttpRequestAttributes.method) as HttpMethod + httpRequest?.method ?? defaultHttpRequestAttributes.methodpackages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts (4)
Line range hint
158-172: Update parameter and variable names fromwebhooktohttpRequestWithin the
parseWebhookAttributesfunction (lines 158-172), the parameters and local variables are namedwebhook, but they represent an HTTP request. To maintain consistency, consider renaming these tohttpRequest.
Line range hint
180-225: Rename parameterwebhooktohttpRequestinexecuteHttpRequestfunctionIn the
executeHttpRequestfunction starting at line 180, the parameter is namedwebhook, but it represents an HTTP request. For consistency and readability, consider renaming the parameter tohttpRequest. This will align with the function's purpose and the overall refactoring.
Line range hint
53-105: Ensure all references towebhookare updated inexecuteHttpRequestBlockIn the
executeHttpRequestBlockfunction (lines 53-105), variables such aswebhookare still used to represent HTTP requests. To maintain consistency with the refactoring, consider renaming these variables tohttpRequest. This includes the variable declarations and any associated logic.
Line range hint
180-225: Update log descriptions to reflect HTTP requestsIn the
executeHttpRequestfunction (lines 180-225), log descriptions such aswebhookSuccessDescriptionandwebhookErrorDescriptionare used. Since the functionality has shifted to HTTP requests, consider renaming these constants and updating their values to accurately describe the operation.Apply this diff to update the constants:
-export const webhookSuccessDescription = `Webhook successfuly executed.`; -export const webhookErrorDescription = `Webhook returned an error.`; +export const httpRequestSuccessDescription = `HTTP request successfully executed.`; +export const httpRequestErrorDescription = `HTTP request returned an error.`;And update their usage within the function:
logs.push({ status: "success", - description: webhookSuccessDescription, + description: httpRequestSuccessDescription, details: { statusCode: response.status, response: typeof body === "string" ? safeJsonParse(body).data : body, request, }, });
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (24)
.github/workflows/deploy-partykit.ymlis excluded by!**/*.ymlapps/builder/package.jsonis excluded by!**/*.jsonapps/builder/src/test/assets/typebots/integrations/httpRequest.jsonis excluded by!**/*.jsonapps/builder/src/test/assets/typebots/logic/webhook.jsonis excluded by!**/*.jsonapps/docs/images/blocks/integrations/http-request/preview.pngis excluded by!**/*.png,!**/*.pngapps/docs/images/blocks/integrations/http-request/save-in-variable.pngis excluded by!**/*.png,!**/*.pngapps/docs/images/blocks/integrations/http-request/simple-post.pngis excluded by!**/*.png,!**/*.pngapps/docs/images/blocks/integrations/http-request/variable-test-value.pngis excluded by!**/*.png,!**/*.pngapps/docs/images/blocks/integrations/http-request/variable-url.pngis excluded by!**/*.png,!**/*.pngapps/docs/mint.jsonis excluded by!**/*.jsonapps/docs/openapi/builder.jsonis excluded by!**/*.jsonapps/docs/openapi/viewer.jsonis excluded by!**/*.jsonapps/viewer/package.jsonis excluded by!**/*.jsonbun.lockbis excluded by!**/bun.lockbpackage.jsonis excluded by!**/*.jsonpackages/embeds/js/package.jsonis excluded by!**/*.jsonpackages/embeds/nextjs/package.jsonis excluded by!**/*.jsonpackages/embeds/react/package.jsonis excluded by!**/*.jsonpackages/partykit/package.jsonis excluded by!**/*.jsonpackages/partykit/partykit.jsonis excluded by!**/*.jsonpackages/partykit/tsconfig.jsonis excluded by!**/*.jsonpackages/tsconfig/base.jsonis excluded by!**/*.jsonpackages/tsconfig/nextjs.jsonis excluded by!**/*.jsonyarn.lockis excluded by!**/yarn.lock,!**/*.lock,!**/*.lock
📒 Files selected for processing (81)
- .gitignore (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/api/getResultExample.ts (2 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/api/listHttpRequestBlocks.ts (4 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/api/router.ts (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/api/subscribeHttpRequest.ts (3 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/api/unsubscribeHttpRequest.ts (3 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestAdvancedConfigForm.tsx (8 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestNodeContent.tsx (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestSettings.tsx (2 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/components/KeyValueInputs.tsx (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/components/ResponseMappingInputs.tsx (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/components/VariableForTestInputs.tsx (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/helpers/convertVariablesForTestToVariables.ts (1 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/httpRequest.spec.ts (2 hunks)
- apps/builder/src/features/blocks/integrations/httpRequest/queries/executeHttpRequestQuery.ts (1 hunks)
- apps/builder/src/features/blocks/integrations/makeCom/components/MakeComSettings.tsx (1 hunks)
- apps/builder/src/features/blocks/integrations/pabbly/components/PabblyConnectSettings.tsx (1 hunks)
- apps/builder/src/features/blocks/integrations/webhook/api/router.ts (0 hunks)
- apps/builder/src/features/blocks/integrations/zapier/components/ZapierSettings.tsx (1 hunks)
- apps/builder/src/features/blocks/logic/webhook/components/WebhookIcon.tsx (1 hunks)
- apps/builder/src/features/blocks/logic/webhook/components/WebhookNodeContent.tsx (1 hunks)
- apps/builder/src/features/blocks/logic/webhook/components/WebhookSettings.tsx (1 hunks)
- apps/builder/src/features/blocks/logic/webhook/webhook.spec.ts (1 hunks)
- apps/builder/src/features/editor/components/BlockIcon.tsx (2 hunks)
- apps/builder/src/features/editor/components/BlockLabel.tsx (4 hunks)
- apps/builder/src/features/editor/components/BlocksSideBar.tsx (2 hunks)
- apps/builder/src/features/editor/providers/typebotActions/blocks.ts (1 hunks)
- apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx (3 hunks)
- apps/builder/src/features/graph/components/nodes/block/SettingsPopoverContent.tsx (4 hunks)
- apps/builder/src/features/graph/helpers/getHelpDocUrl.ts (2 hunks)
- apps/builder/src/helpers/server/routers/publicRouter.ts (2 hunks)
- apps/builder/src/lib/theme.ts (3 hunks)
- apps/builder/src/pages/api/typebots/[typebotId]/blocks/[blockId]/testHttpRequest.ts (3 hunks)
- apps/docs/editor/blocks/inputs/email.mdx (1 hunks)
- apps/docs/editor/blocks/inputs/website.mdx (1 hunks)
- apps/docs/editor/blocks/integrations/http-request.mdx (4 hunks)
- apps/docs/editor/blocks/logic/wait.mdx (1 hunks)
- apps/docs/editor/blocks/logic/webhook.mdx (1 hunks)
- apps/viewer/src/pages/api/typebots/[typebotId]/blocks/[blockId]/executeWebhook.ts (3 hunks)
- apps/viewer/src/pages/api/typebots/[typebotId]/webhookBlocks.ts (2 hunks)
- apps/viewer/src/pages/api/typebots/[typebotId]/webhookSteps.ts (2 hunks)
- apps/viewer/src/pages/api/v1/typebots/[typebotId]/blocks/[blockId]/results/[resultId]/executeWebhook.ts (1 hunks)
- apps/viewer/src/pages/api/v1/typebots/[typebotId]/blocks/[blockId]/web/executeTestWebhook.ts (1 hunks)
- apps/viewer/src/pages/api/v1/typebots/[typebotId]/blocks/[blockId]/whatsapp/[phone]/executeTestWebhook.ts (1 hunks)
- packages/blocks/core/src/helpers.ts (2 hunks)
- packages/blocks/core/src/migrations/migrateWebhookBlock.ts (2 hunks)
- packages/blocks/integrations/src/constants.ts (1 hunks)
- packages/blocks/integrations/src/httpRequest/constants.ts (1 hunks)
- packages/blocks/integrations/src/httpRequest/schema.ts (1 hunks)
- packages/blocks/integrations/src/makeCom/schema.ts (1 hunks)
- packages/blocks/integrations/src/pabblyConnect/schema.ts (1 hunks)
- packages/blocks/integrations/src/schema.ts (1 hunks)
- packages/blocks/integrations/src/zapier/schema.ts (1 hunks)
- packages/blocks/logic/src/constants.ts (1 hunks)
- packages/blocks/logic/src/schema.ts (2 hunks)
- packages/blocks/logic/src/webhook/schema.ts (1 hunks)
- packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts (8 hunks)
- packages/bot-engine/src/blocks/integrations/httpRequest/saveDataInResponseVariableMapping.ts (3 hunks)
- packages/bot-engine/src/blocks/logic/webhook/executeWebhookBlock.ts (1 hunks)
- packages/bot-engine/src/continueBotFlow.ts (2 hunks)
- packages/bot-engine/src/executeIntegration.ts (2 hunks)
- packages/bot-engine/src/executeLogic.ts (2 hunks)
- packages/bot-engine/src/logs/filterPotentiallySensitiveLogs.ts (1 hunks)
- packages/bot-engine/src/saveStateToDatabase.ts (3 hunks)
- packages/bot-engine/src/schemas/api.ts (1 hunks)
- packages/bot-engine/src/schemas/clientSideAction.ts (3 hunks)
- packages/deprecated/bot-engine/src/features/blocks/integrations/webhook/utils/executeWebhookBlock.ts (1 hunks)
- packages/deprecated/bot-engine/src/utils/executeIntegration.ts (1 hunks)
- packages/embeds/js/src/components/ConversationContainer/ConversationContainer.tsx (1 hunks)
- packages/embeds/js/src/features/blocks/integrations/httpRequest/executeHttpRequest.ts (1 hunks)
- packages/embeds/js/src/features/blocks/logic/script/executeScript.ts (0 hunks)
- packages/embeds/js/src/features/blocks/logic/webhook/listenForWebhook.ts (1 hunks)
- packages/embeds/js/src/queries/startChatQuery.ts (2 hunks)
- packages/embeds/js/src/types.ts (1 hunks)
- packages/embeds/js/src/utils/executeClientSideActions.ts (3 hunks)
- packages/env/src/index.ts (3 hunks)
- packages/partykit/src/webhookServer.ts (1 hunks)
- packages/typebot/src/migrations/migrateTypebotFromV3ToV4.ts (2 hunks)
- packages/whatsapp/src/resumeWhatsAppFlow.ts (8 hunks)
- packages/whatsapp/src/schemas.ts (1 hunks)
- packages/whatsapp/src/sendChatReplyToWhatsApp.ts (6 hunks)
💤 Files with no reviewable changes (2)
- apps/builder/src/features/blocks/integrations/webhook/api/router.ts
- packages/embeds/js/src/features/blocks/logic/script/executeScript.ts
✅ Files skipped from review due to trivial changes (1)
- .gitignore
🧰 Additional context used
🪛 LanguageTool
apps/docs/editor/blocks/inputs/email.mdx
[style] ~31-~31: Consider a more expressive alternative.
Context: ...k if the email address is valid. To do that, you will have to trigger a [HTTP ...(DO_ACHIEVE)
apps/docs/editor/blocks/inputs/website.mdx
[style] ~31-~31: Consider a more expressive alternative.
Context: ...k if the email address is valid. To do that, you will have to trigger a [HTTP ...(DO_ACHIEVE)
apps/docs/editor/blocks/logic/webhook.mdx
[style] ~40-~40: Consider a shorter alternative to avoid wordiness.
Context: ...e Webhook URL needs to be authenticated in order to work. See [API authentication](/api-ref...(IN_ORDER_TO_PREMIUM)
🔇 Additional comments (162)
packages/blocks/logic/src/constants.ts (1)
10-10: Verify impact on switch statements using this enum.Adding a new enum member is generally safe, but it's important to ensure that any exhaustive switch statements using
LogicBlockTypeare updated to handle the newWEBHOOKcase.To help identify potential switch statements that might need updating, you can run the following script:
Please review the output and update any switch statements or related code as necessary.
packages/blocks/integrations/src/constants.ts (1)
5-5: Verify impact on existing codebaseThe renaming of
WEBHOOKtoHTTP_REQUESTmay impact other parts of the codebase that reference this enum member. Ensure that all occurrences ofIntegrationBlockType.WEBHOOKhave been updated toIntegrationBlockType.HTTP_REQUEST.Let's run a script to check for any remaining references to the old enum member name:
#!/bin/bash # Search for any remaining references to IntegrationBlockType.WEBHOOK echo "Searching for remaining IntegrationBlockType.WEBHOOK references:" rg --type typescript "IntegrationBlockType\.WEBHOOK"If any results are found, they will need to be updated to use the new enum member name.
packages/bot-engine/src/blocks/logic/webhook/executeWebhookBlock.ts (1)
1-2: LGTM: Import statements are appropriate and well-structured.The import statements are correctly using type imports, which is a good TypeScript practice. The module paths suggest a well-organized project structure.
apps/builder/src/features/blocks/integrations/httpRequest/api/router.ts (1)
1-5: LGTM: Imports are appropriate and consistent.The imports are well-organized, importing the necessary router utility and local functions for HTTP request operations.
apps/builder/src/features/blocks/integrations/httpRequest/queries/executeHttpRequestQuery.ts (4)
Line range hint
1-15: Summary: Changes align well with PR objectivesThe modifications in this file effectively transform the webhook functionality into a more general HTTP request functionality. This change aligns well with the PR objective of adding a webhook block, as it provides a solid foundation for webhook implementation.
Key points:
- The import path has been updated to reflect the new HTTP request focus.
- The function name has been changed to
executeHttpRequest, accurately representing its new purpose.- The API endpoint in the
sendRequestcall has been updated to usetestHttpRequest.These changes contribute to the overall goal of adding a webhook option to the Wait block (issue #1531) by generalizing the HTTP request functionality, which can be used to implement webhooks.
5-9: LGTM! Verify function usage consistency across the codebase.The function name has been appropriately updated from
executeWebhooktoexecuteHttpRequest, which accurately reflects its new purpose. The function signature and parameters remain unchanged, maintaining consistency in usage.To ensure all function calls have been updated, run the following script:
#!/bin/bash # Description: Check for any remaining calls to the old executeWebhook function # Test: Search for any remaining calls to executeWebhook rg --type typescript 'executeWebhook\s*\(' # Expected result: No matches found, indicating all function calls have been updated
Line range hint
10-15: LGTM! Verify backend API endpoint.The URL in the
sendRequestcall has been correctly updated to/api/typebots/${typebotId}/blocks/${blockId}/testHttpRequest, which is consistent with the shift from webhook to HTTP request functionality.To ensure the backend API has been updated to handle this new endpoint, please verify the following:
- Check if the corresponding backend route has been updated:
#!/bin/bash # Description: Search for the new API route in the backend code # Test: Look for the new testHttpRequest route rg --type typescript '/api/typebots/\$\{typebotId\}/blocks/\$\{blockId\}/testHttpRequest' # Expected result: At least one match found, indicating the new route has been implemented
- If the backend code is in a separate repository, please manually verify that the API endpoint has been updated to handle the new
testHttpRequestroute.
1-1: LGTM! Verify import consistency across the codebase.The import statement has been correctly updated to reflect the change from webhook to HTTP request functionality. This change aligns well with the new purpose of the function.
To ensure consistency, let's verify that all relevant imports have been updated:
packages/bot-engine/src/logs/filterPotentiallySensitiveLogs.ts (2)
Line range hint
1-21: Verify related changes across the codebase.The change in import source for webhook-related constants suggests a possible restructuring of webhook functionality. This aligns with the PR objective of adding a webhook block and addressing issue #1531 (adding a webhook option to the Wait block).
To ensure consistency across the codebase:
- Check for other files that might need similar import updates.
- Verify that the new webhook block implementation is properly integrated with existing functionality.
Run the following script to identify potential areas that might need updates:
#!/bin/bash # Description: Find other files that might need import updates and check for the new webhook block implementation # Test 1: Find other files importing from the old webhook path rg -t typescript "from ['\"]../blocks/integrations/webhook/executeWebhookBlock['\"]" packages/bot-engine/src # Test 2: Check for new webhook block implementation rg -t typescript "class WebhookBlock" packages/bot-engine/src # Test 3: Check for updates to the Wait block related to webhooks rg -t typescript "class WaitBlock" packages/bot-engine/srcPlease review the results and ensure all necessary updates have been made.
1-4: LGTM. Verify the new import source and update related documentation.The change in import source for
webhookErrorDescriptionandwebhookSuccessDescriptionlooks good. This modification appears to align with the PR objective of adding a webhook block, possibly consolidating webhook-related functionality with HTTP requests.Please ensure that:
- The new import source
../blocks/integrations/httpRequest/executeHttpRequestBlockis correct and the imported constants are available.- Any related documentation or comments referencing these imports are updated accordingly.
Run the following script to verify the new import source:
✅ Verification successful
Verified the import changes successfully.
The new import source../blocks/integrations/httpRequest/executeHttpRequestBlockexists, and bothwebhookErrorDescriptionandwebhookSuccessDescriptionare correctly exported. No issues found with the import modifications.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of the new import source and the exported constants # Test 1: Check if the file exists fd -p "packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts$" # Test 2: Check if the constants are exported from the file rg -t typescript "export const (webhookErrorDescription|webhookSuccessDescription)" packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.tsLength of output: 344
Script:
#!/bin/bash # Description: Verify the existence of the new import source and the exported constants without specifying file type # Test 1: Check if the file exists fd "packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts$" # Test 2: Check if the constants are exported from the file grep -E "export const (webhookErrorDescription|webhookSuccessDescription)" packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.tsLength of output: 393
packages/blocks/integrations/src/httpRequest/constants.ts (2)
15-17: Approved: Improved naming conventionThe renaming of
defaultWebhookAttributestodefaultHttpRequestAttributesis a positive change. It more accurately reflects the purpose of the constant, which is to define default attributes for HTTP requests in general, not just for webhooks. This naming convention aligns better with the broader scope of HTTP requests and improves code clarity.
Line range hint
1-28: Summary: Improved naming conventions for HTTP request constantsThe changes in this file focus on renaming two constants to better reflect their purpose in the context of HTTP requests. These modifications enhance code clarity and maintain consistency throughout the codebase. The functionality remains unchanged, and the type safety is preserved through the use of
as constandsatisfieskeywords.The renaming aligns well with the PR objective of adding a webhook block, as it generalizes the constants to cover broader HTTP request scenarios, which can include webhook implementations.
apps/builder/src/features/blocks/logic/webhook/components/WebhookIcon.tsx (3)
1-2: LGTM: Imports are well-structured and appropriate.The imports are concise and well-organized, utilizing named imports for better tree-shaking. The use of the
@/alias for internal imports is consistent with best practices for path aliasing.
4-4: LGTM: Component declaration is clear and type-safe.The
WebhookIconcomponent is correctly declared as a functional component using an arrow function. The use ofIconPropsfrom Chakra UI ensures type safety and consistency with the Chakra UI ecosystem.
1-15: Overall assessment: Well-implemented component that aligns with PR objectives.The
WebhookIconcomponent is a solid addition that aligns well with the PR's objective of adding webhook functionality. It follows React and Chakra UI best practices, providing a clean, type-safe, and flexible implementation. The component's design allows for easy integration into the existing system and supports both light and dark modes.Great job on this implementation! The only minor suggestion is to consider extracting the SVG paths for improved maintainability, but this is not critical for the current implementation.
packages/blocks/integrations/src/makeCom/schema.ts (2)
Line range hint
1-28: LGTM! Changes are well-integrated and backwards-compatible.The import change has been seamlessly integrated into the existing code structure. The usage of
httpBlockSchemasremains consistent throughout the file, indicating that the change is backwards-compatible. ThemakeComBlockSchemasandmakeComBlockSchemadefinitions are unaffected, preserving the existing functionality.This change appears to be part of a larger refactoring effort. To maintain consistency across the codebase:
- Ensure that all files importing from the old
"../webhook/schema"path are updated to use"../httpRequest/schema".- Update any relevant documentation or comments that might reference the old import path.
- If there are any tests related to this file or the
httpBlockSchemas, verify that they still pass with the new import.
3-3: LGTM! Verify import compatibility and update documentation.The change from
"../webhook/schema"to"../httpRequest/schema"looks good. This refactoring improves code organization by movinghttpBlockSchemasto a more appropriate module.To ensure everything works as expected:
- Verify that the
httpBlockSchemasfrom the new import location is fully compatible with its usage in this file.- Update any related documentation or comments that might reference the old import path.
Run the following script to check for any other occurrences of the old import path:
If the script returns results, consider updating those imports as well for consistency.
✅ Verification successful
LGTM! Import path change verified and documentation updated.
The change from
"../webhook/schema"to"../httpRequest/schema"has been verified with no other occurrences found. This refactoring improves code organization by movinghttpBlockSchemasto a more appropriate module.
- Ensure related documentation or comments referencing the old import path are updated accordingly.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of the old import path # Test: Search for other imports from "../webhook/schema" rg --type typescript 'from "../webhook/schema"'Length of output: 84
Script:
#!/bin/bash # Description: Check for other occurrences of the old import path # Corrected Test: Search for other imports from "../webhook/schema" using the correct TypeScript file type rg --type=ts 'from "../webhook/schema"'Length of output: 41
packages/blocks/integrations/src/pabblyConnect/schema.ts (1)
3-3: LGTM! Verify consistency across the codebase.The change from importing
httpBlockSchemasfrom "../webhook/schema" to "../httpRequest/schema" looks good. This refactoring aligns with the PR objective of adding a webhook block, suggesting a consolidation of HTTP-related schemas.To ensure this change is consistent and doesn't introduce issues elsewhere, please run the following script:
This script will help verify that:
- There are no remaining imports from the old path.
- There are no usages of potentially outdated 'webhookBlockSchemas'.
- The
httpBlockSchemasis properly exported from the new location.packages/embeds/js/src/features/blocks/integrations/httpRequest/executeHttpRequest.ts (2)
3-4: LGTM! Verify function usage across the codebase.The function and parameter renaming from
executeWebhookandwebhookToExecutetoexecuteHttpRequestandhttpRequestToExecuterespectively is consistent with the more general HTTP request approach. This change improves clarity and aligns well with the new import path.To ensure all callers of this function have been updated, let's verify its usage across the codebase:
#!/bin/bash # Description: Check for any remaining usage of the old function name and verify the new function name usage # Test: Search for any remaining usage of the old function name rg --type typescript 'executeWebhook' # Test: Verify the new function name is used consistently rg --type typescript 'executeHttpRequest'
1-1: LGTM! Verify import consistency across the codebase.The import path change from "webhook" to "httpRequest" aligns well with the function renaming. This change suggests a shift towards a more general HTTP request handling approach.
To ensure consistency, let's verify the import usage across the codebase:
apps/docs/editor/blocks/logic/wait.mdx (1)
Line range hint
1-20: Overall structure and content of the Wait block documentation looks goodThe changes made to this file improve the documentation by adding a cautionary note while maintaining the essential information about the Wait block's functionality. The file structure remains coherent:
- Introduction to the Wait block
- New warning message
- Specific use case ("Pause the flow")
This structure provides a good balance of information, caution, and practical application. The content effectively guides users on how to use the Wait block appropriately.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~8-~8: A comma might be missing here.
Context: ...on what's been said or to wait before a redirection for example to make sure the user has r...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
[uncategorized] ~8-~8: A comma might be missing here.
Context: ...aid or to wait before a redirection for example to make sure the user has read everythi...(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)
packages/blocks/integrations/src/zapier/schema.ts (1)
3-3: Verify the impact of the import change on Zapier integration.The import path for
httpBlockSchemashas been updated from "../webhook/schema" to "../httpRequest/schema". This change appears to be part of a refactoring effort.
- Please confirm that this change aligns with the intended refactoring of the webhook functionality mentioned in the PR objectives.
- Ensure that the Zapier integration still functions as expected with this new import.
- If this change represents a significant shift in how webhooks are handled, consider updating any relevant documentation to reflect this change.
To verify the impact of this change, please run the following script:
✅ Verification successful
Import change verified: No remaining references to old webhook schema
The updated import path for
httpBlockSchemashas been successfully verified. There are no remaining references to the old webhook schema, the newhttpRequest/schema.tsexists, and all instances ofhttpBlockSchemashave been updated accordingly. The Zapier integration should function as expected with this change.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining references to the old webhook schema and verify the new httpRequest schema exists # Test 1: Check for any remaining references to the old webhook schema echo "Checking for remaining references to webhook schema:" rg --type typescript 'from "../webhook/schema"' # Test 2: Verify the existence of the new httpRequest schema echo "Verifying existence of new httpRequest schema:" fd --type file --full-path '.*httpRequest/schema.ts$' # Test 3: Check for other occurrences of httpBlockSchemas to ensure consistency echo "Checking other occurrences of httpBlockSchemas:" rg --type typescript 'import.*httpBlockSchemas'Length of output: 603
Script:
#!/bin/bash # Description: Check for any remaining references to the old webhook schema and verify the new httpRequest schema exists # Test 1: Check for any remaining references to the old webhook schema echo "Checking for remaining references to webhook schema:" rg -g "*.ts" 'from "\.\./webhook/schema"' # Test 2: Verify the existence of new httpRequest schema echo "Verifying existence of new httpRequest schema:" fd --type file --full-path '.*httpRequest/schema.ts$' # Test 3: Check for other occurrences of httpBlockSchemas to ensure consistency echo "Checking other occurrences of httpBlockSchemas:" rg -g "*.ts" 'import.*httpBlockSchemas'Length of output: 951
packages/blocks/logic/src/webhook/schema.ts (2)
1-3: LGTM: Imports are appropriate and well-structured.The imports are correctly bringing in the necessary dependencies for defining the webhook schemas.
29-29: LGTM: Type export enhances type safety.Exporting the
WebhookBlocktype inferred from the schema is a good practice. It ensures type consistency and makes it easier to use the webhook block type throughout the application.packages/embeds/js/src/features/blocks/logic/webhook/listenForWebhook.ts (3)
1-2: LGTM: Imports are appropriate for the functionality.The imports of
envandPartySocketare well-chosen for implementing webhook listening functionality using WebSockets and environment variables.
4-7: LGTM: Well-defined Props type.The
Propstype is clearly defined with appropriate optionality forresultIdand a requiredsessionId. This structure provides flexibility while ensuring necessary information is always provided.
23-27: LGTM: Clear and concise room name generation.The
getRoomNamefunction is well-implemented:
- It handles different scenarios based on the presence of
resultId.- The string interpolation for room names is clear and easy to understand.
- The destructuring of
sessionIdis efficient.apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestNodeContent.tsx (2)
10-10: LGTM! Verify component usage updates.The renaming of the component from
WebhookContenttoHttpRequestNodeContentis a positive change. It provides a more accurate description of the component's purpose and aligns well with the PR objective of adding a webhook block.To ensure that this change has been properly propagated, please run the following script to check for any remaining usage of the old component name and confirm the usage of the new name:
✅ Verification successful
Please run the updated verification script below to check for any remaining usage of the old component name and confirm the usage of the new name:
Verified: The component renaming from
WebhookContenttoHttpRequestNodeContenthas been successfully propagated throughout the codebase. No remaining usages ofWebhookContentwere found, and all instances have been updated toHttpRequestNodeContentas expected.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining usage of the old component name and new component name usage echo "Checking for old component name usage:" rg --type typescript 'WebhookContent' echo "Checking for new component name usage:" rg --type typescript 'HttpRequestNodeContent'Length of output: 327
Script:
# #!/bin/bash # Description: Check for any remaining usage of the old component name and new component name usage echo "Checking for old component name usage:" rg 'WebhookContent' --glob '*.ts' --glob '*.tsx' echo "Checking for new component name usage:" rg 'HttpRequestNodeContent' --glob '*.ts' --glob '*.tsx'Length of output: 776
4-4: LGTM! Verify consistency of import path change.The update to the import statement for
HttpRequestBlocktype is in line with the PR objective of adding a webhook block. This change suggests a positive restructuring of the codebase to accommodate the new feature.To ensure consistency, please run the following script to check if this import path has been updated across the codebase:
✅ Verification successful
Import path changes verified successfully.
The import statement for
HttpRequestBlockhas been consistently updated across the codebase, with no remaining references to the old import path.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining imports from the old path and new path usage echo "Checking for old import path usage:" rg --type typescript 'from\s+["'\'']@typebot\.io/blocks-integrations/webhook/schema["'\'']' echo "Checking for new import path usage:" rg --type typescript 'from\s+["'\'']@typebot\.io/blocks-integrations/httpRequest/schema["'\'']'Length of output: 423
Script:
#!/bin/bash # Description: Check for any remaining imports from the old path and confirm new import path usage echo "Checking for old import path usage:" rg 'from\s+["'"'"']@typebot\.io/blocks-integrations/webhook/schema["'"'"']' --glob '*.ts' --glob '*.tsx' echo "Checking for new import path usage:" rg 'from\s+["'"'"']@typebot\.io/blocks-integrations/httpRequest/schema["'"'"']' --glob '*.ts' --glob '*.tsx'Length of output: 4805
apps/builder/src/features/blocks/logic/webhook/components/WebhookNodeContent.tsx (2)
1-6: LGTM: Imports are appropriate and necessary.The imports cover all the required components, hooks, and utilities needed for the WebhookNodeContent component. The separate import of React is correct for versions of React that require it for JSX.
8-10: LGTM: Props type is well-defined.The Props type is correctly defined with a single 'options' property of type WebhookBlock["options"]. This ensures type safety and clear expectations for the component's props.
packages/embeds/js/src/types.ts (1)
24-24: LGTM: Addition ofresultIdtoClientSideActionContextThe addition of the optional
resultIdproperty to theClientSideActionContexttype is a good change. It aligns this type more closely with theBotContexttype, which also includes aresultId. This consistency in type definitions can improve code clarity and maintainability.A few observations:
- The new property is correctly marked as optional (
?), which maintains backwards compatibility.- The type of
resultId(string) matches the type used inBotContext, ensuring consistency.- This change might indicate that client-side actions now have access to or need the
resultId, which could be useful for tracking or linking actions to specific results.To ensure this change is used consistently across the codebase, let's check for any other occurrences of
ClientSideActionContext:This will help verify if any other parts of the code need to be updated to accommodate this change.
✅ Verification successful
**** The addition of the optional
resultIdproperty toClientSideActionContextis correctly implemented and consistently handled across the codebase. No issues were found related to this change.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for other uses of ClientSideActionContext rg --type typescript "ClientSideActionContext" -C 3Length of output: 86
Script:
#!/bin/bash # Search for other uses of ClientSideActionContext with correct file type rg --type ts "ClientSideActionContext" -C 3Length of output: 2954
Script:
#!/bin/bash # Search for usage of 'resultId' in files where 'ClientSideActionContext' is used rg "resultId" packages/embeds/js/src/types.ts packages/embeds/js/src/utils/executeClientSideActions.ts packages/embeds/js/src/features/blocks/integrations/openai/streamChat.ts -C 3Length of output: 1491
packages/typebot/src/migrations/migrateTypebotFromV3ToV4.ts (2)
15-15: Approve function body change and verify block structure.The update to use
isHttpRequestBlockfor filtering is consistent with the import change and correctly implements the migration to HTTP request blocks.To ensure the structure of HTTP request blocks is compatible with the existing logic, please run the following script:
#!/bin/bash # Description: Compare the structure of WebhookBlock and HttpRequestBlock # Test 1: Check the structure of WebhookBlock echo "Structure of WebhookBlock:" ast-grep --lang typescript --pattern $'interface WebhookBlock { $$$ }' # Test 2: Check the structure of HttpRequestBlock echo "Structure of HttpRequestBlock:" ast-grep --lang typescript --pattern $'interface HttpRequestBlock { $$$ }'This script will help verify that the
HttpRequestBlockstructure is compatible with the existing logic that was previously used forWebhookBlock.
1-1: Approve import change and verify its impact.The change from
isWebhookBlocktoisHttpRequestBlockis appropriate and aligns with the migration from webhook blocks to HTTP request blocks. This change improves the flexibility of the system.To ensure this change is consistent across the codebase, please run the following script:
This script will help identify any inconsistencies in the migration from webhook blocks to HTTP request blocks across the codebase.
apps/builder/src/features/blocks/integrations/httpRequest/helpers/convertVariablesForTestToVariables.ts (3)
Line range hint
2-38: Confirmed: No changes required in function implementations.The rest of the file, including the
convertVariablesForTestToVariablesandparseVariableValuefunctions, remains unchanged. This suggests that theVariableForTestinterface has maintained consistency despite the move from 'webhook' to 'httpRequest' schema. The lack of changes in the function implementations is a positive indication that the refactoring was done cleanly.
Line range hint
1-38: Overall assessment: Clean implementation of import change.The change in this file is limited to updating the import path for the
VariableForTesttype. This modification aligns with the PR objective of adding a webhook block and appears to be part of a larger refactoring effort. The implementation is clean, and the lack of changes in the rest of the file suggests that the refactoring was done carefully, maintaining the consistency of theVariableForTestinterface.To ensure a smooth transition, it would be beneficial to:
- Verify that all other files using the
VariableForTesttype have been updated accordingly.- Run the entire test suite to catch any potential issues that might have been introduced by this change.
- Update any documentation or comments that might reference the old import path.
1-1: LGTM! Verify impact on other files.The import statement has been updated to reflect the new location of the
VariableForTesttype. This change aligns with the PR objective of adding a webhook block and suggests a refactoring of the project structure.To ensure this change doesn't introduce any issues, please run the following script to check for any other occurrences of the old import path:
This will help identify any files that might need updating to use the new import path.
✅ Verification successful
Verified: Import path updated consistently across the codebase.
All occurrences of
"@typebot.io/blocks-integrations/webhook/schema"have been successfully updated to"@typebot.io/blocks-integrations/httpRequest/schema", ensuring consistency with the PR objectives.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining occurrences of the old import path # Test: Search for the old import path rg --type typescript '"@typebot.io/blocks-integrations/webhook/schema"' # Test: Verify that the new import path is used consistently rg --type typescript '"@typebot.io/blocks-integrations/httpRequest/schema"'Length of output: 221
Script:
#!/bin/bash # Description: Check for any remaining occurrences of the old import path # Test: Search for the old import path using the correct file type identifier rg --type ts '"@typebot.io/blocks-integrations/webhook/schema"' # Test: Verify that the new import path is used consistently rg --type ts '"@typebot.io/blocks-integrations/httpRequest/schema"'Length of output: 4565
apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestSettings.tsx (4)
Line range hint
1-43: Summary: Consistent renaming improves code clarityThe changes in this file are part of a broader effort to rename 'webhook' to 'httpRequest' throughout the codebase. This renaming improves code clarity and consistency. The changes are well-implemented and don't introduce any apparent issues.
Key points:
- Import path updated to reflect the new naming convention.
- Prop names changed consistently from 'webhook' to 'httpRequest'.
- Function names updated to match the new terminology.
These changes should make the code more maintainable and easier to understand. Good job on maintaining consistency throughout the file!
36-36: LGTM! Verify prop usage in parent component.The prop name change from
webhooktohttpRequestimproves clarity and consistency with the import changes. This is a positive change that makes the code more self-descriptive.To ensure that this change doesn't break anything, please verify that the parent component passing this prop has been updated accordingly. Run the following script to locate the parent component:
#!/bin/bash # Description: Find the parent component that renders HttpRequestSettings # Test: Search for components rendering HttpRequestSettings. Expect: One or more results showing the updated prop name. rg --type typescript -A 5 '<HttpRequestSettings'
38-38: LGTM! Verify prop usage in parent and current component.The prop name change from
onWebhookChangetoonHttpRequestChangeis consistent with the previous changes and improves the overall clarity of the code.To ensure that this change is properly implemented, please verify:
- The parent component has been updated to pass the correct prop name.
- Any internal usage of this prop (if any) has been updated.
Run the following scripts:
#!/bin/bash # Description: Check parent component and internal usage of the changed prop # Test 1: Find the parent component rendering HttpRequestSettings # Expect: One or more results showing the updated prop name rg --type typescript -A 5 '<HttpRequestSettings' # Test 2: Check for any remaining usage of 'onWebhookChange' in this file # Expect: No results rg --type typescript 'onWebhookChange' apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestSettings.tsx
6-6: LGTM! Verify imports across the codebase.The import path update from 'webhook' to 'httpRequest' reflects a more specific naming convention, which is good. This change improves code organization and clarity.
To ensure consistency, please verify that all imports of
HttpRequestandHttpRequestBlocktypes have been updated across the codebase. Run the following script to check for any remaining imports from the old path:packages/blocks/logic/src/schema.ts (2)
10-10: LGTM: New import for webhook block schema.The addition of the
webhookBlockSchemaimport is consistent with the existing code structure and aligns with the PR objective of adding a webhook block.
Line range hint
1-38: Additional considerations for the PR.The changes look good and are well-integrated into the existing code structure. To ensure a comprehensive implementation of the new webhook block, consider the following:
- Update any relevant documentation to reflect the addition of the webhook block.
- Add or update unit tests to cover the new
webhookBlockSchemain the logic block schemas.- Verify that any components or functions that work with logic blocks are updated to handle the new webhook block type.
To help verify the integration, you can run the following script to check for any files that might need updates:
This will help identify areas of the codebase that might need attention due to the new webhook block addition.
apps/builder/src/features/blocks/integrations/httpRequest/components/VariableForTestInputs.tsx (1)
5-5: LGTM! Verify the new import path.The change in the import statement from webhook to httpRequest schema aligns with the PR objective of adding a Webhook block. This modification suggests a separation of concerns between webhook and HTTP request functionalities, which is a good practice.
To ensure the new import path is correct and the
VariableForTesttype is available, please run the following verification script:apps/docs/editor/blocks/logic/webhook.mdx (2)
1-8: LGTM: Clear and informative introductionThe header and introduction effectively explain the purpose and use case of the Webhook block. The metadata is correctly formatted, and the explanation is concise and relevant.
1-40: Overall: Well-structured and informative documentationThis new documentation for the Webhook block is clear, concise, and well-organized. It effectively explains the purpose of the block and provides necessary information for both test and production environments.
Main suggestions for improvement:
- Add explanations for obtaining the
{typebotId}and{blockId}parameters.- Enhance the explanation of the
{phone}parameter formatting.- Consider minor wording improvements for clarity and conciseness.
These enhancements will further improve the already high-quality documentation, making it even more user-friendly and comprehensive.
🧰 Tools
🪛 LanguageTool
[style] ~40-~40: Consider a shorter alternative to avoid wordiness.
Context: ...e Webhook URL needs to be authenticated in order to work. See [API authentication](/api-ref...(IN_ORDER_TO_PREMIUM)
apps/builder/src/helpers/server/routers/publicRouter.ts (3)
Line range hint
1-32: Overall assessment: Changes look good, pending verification.The modifications in this file are consistent with the PR objectives of adding a webhook block. The change from
webhooktohttpRequestsuggests a more generic approach, which could provide greater flexibility. However, it's crucial to verify the new import path and check for any impacts on the existing codebase.Please run the verification scripts provided in the previous comments to ensure:
- The new import path exists and is structured correctly.
- There are no lingering references to the old webhook router.
- All areas using the public router are updated to use the new
httpRequestproperty.After verification, if any issues are found, please address them before merging this PR.
21-21: LGTM! Verify usage of the new router.The addition of
httpRequest: httpRequestRouterto thepublicRouterobject is consistent with the import changes and aligns with the PR objectives. The naming convention change from "webhook" to "httpRequest" is maintained, suggesting a more generic and potentially versatile approach.Please run the following script to verify the usage of the new router and identify any potential areas that might need updates:
#!/bin/bash # Description: Verify the usage of the new httpRequest router and identify potential areas for updates # Test 1: Check for any remaining references to the old webhook router rg --type typescript 'webhook(Router|:)' -g '!**/publicRouter.ts' # Test 2: Identify potential areas that might need updates rg --type typescript 'publicRouter\.(webhook|httpRequest)' -g '!**/publicRouter.ts'If the script returns any results, please review those areas to ensure they are updated to use the new
httpRequestrouter.
3-3: LGTM! Verify the new import path.The change from
webhookRoutertohttpRequestRouteraligns with the PR objectives and suggests an expansion of functionality. The new naming convention is more generic and potentially more versatile.Please run the following script to verify the existence and structure of the new import path:
packages/deprecated/bot-engine/src/utils/executeIntegration.ts (1)
25-25: Approve the change, but consider further updates for consistency.The renaming from
WEBHOOKtoHTTP_REQUESTis a good change that likely improves clarity and aligns with a more general terminology. However, for full consistency, consider the following:
- Update the
executeWebhookfunction name to match the new terminology, e.g.,executeHttpRequest.- Ensure that any documentation or comments referencing webhooks are updated to reflect this change.
To ensure this change doesn't introduce inconsistencies, let's verify the usage of
IntegrationBlockType.WEBHOOKin other parts of the codebase:✅ Verification successful
Verification Successful: No Remaining
IntegrationBlockType.WEBHOOKReferences Found.The renaming of
IntegrationBlockType.WEBHOOKtoIntegrationBlockType.HTTP_REQUESThas been successfully verified with no remaining references in the codebase. This change enhances clarity and aligns with more general terminology.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining usage of IntegrationBlockType.WEBHOOK # Test 1: Search for IntegrationBlockType.WEBHOOK echo "Searching for IntegrationBlockType.WEBHOOK:" rg --type typescript "IntegrationBlockType\.WEBHOOK" # Test 2: Search for references to webhook in type definitions or enums echo "Searching for webhook references in type definitions or enums:" rg --type typescript "webhook.*[:=]" -i # Test 3: Search for executeWebhook function references echo "Searching for executeWebhook function references:" rg --type typescript "executeWebhook"Length of output: 580
Script:
#!/bin/bash # Description: Re-check for any remaining usage of IntegrationBlockType.WEBHOOK with corrected file type identifiers # Test 1: Search for IntegrationBlockType.WEBHOOK using the correct TypeScript type echo "Searching for IntegrationBlockType.WEBHOOK:" rg --type ts "IntegrationBlockType\.WEBHOOK" # Test 2: Search for references to webhook in type definitions or enums using glob patterns echo "Searching for webhook references in type definitions or enums:" rg --glob '*.ts*' "webhook.*[:=]" -i # Test 3: Search for executeWebhook function references using glob patterns echo "Searching for executeWebhook function references:" rg --glob '*.ts*' "executeWebhook"Length of output: 17193
apps/builder/src/features/blocks/integrations/httpRequest/components/KeyValueInputs.tsx (1)
4-4: LGTM! Verify the new import path.The change in the import statement for the
KeyValuetype aligns well with the file's location in thehttpRequestdirectory. This refactoring improves the organization of types by making them more specific to their usage context.To ensure the correctness of this change, please run the following verification script:
This script will help confirm that:
- The new schema file exists.
- The
KeyValuetype is properly exported from the new location.- There are no remaining imports from the old path, ensuring consistency across the codebase.
apps/builder/src/features/blocks/integrations/httpRequest/components/ResponseMappingInputs.tsx (2)
Line range hint
1-38: Overall assessment: Changes align with PR objectivesThe modification to the import statement aligns with the PR objective of adding a webhook block. The rest of the file remains unchanged and appears to be functioning as intended. The suggested improvements for type safety and prop validation are optional enhancements that could be considered in future iterations.
5-5: Import path updated for ResponseVariableMapping typeThe import path for the
ResponseVariableMappingtype has been changed from@typebot.io/blocks-integrations/webhook/schemato@typebot.io/blocks-integrations/httpRequest/schema. This change aligns with the PR objective of adding a webhook block and potentially refactoring related components.To ensure consistency across the codebase, let's verify if similar changes have been made in other files:
This will help us identify if there are any inconsistencies in import paths across the project.
✅ Verification successful
Import path change verified successfully
All remaining imports from
@typebot.io/blocks-integrations/webhook/schemahave been removed, and the new import path@typebot.io/blocks-integrations/httpRequest/schemais consistently used across the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining imports from the old webhook schema path # and new imports from the httpRequest schema path echo "Checking for remaining imports from webhook schema:" rg --type typescript '@typebot\.io/blocks-integrations/webhook/schema' echo "Checking for new imports from httpRequest schema:" rg --type typescript '@typebot\.io/blocks-integrations/httpRequest/schema'Length of output: 441
Script:
#!/bin/bash # Description: Check for any remaining imports from the old webhook schema path # and new imports from the httpRequest schema path in TypeScript files. echo "Checking for remaining imports from webhook schema:" rg --type ts '@typebot\.io/blocks-integrations/webhook/schema' rg --type tsx '@typebot\.io/blocks-integrations/webhook/schema' echo "Checking for new imports from httpRequest schema:" rg --type ts '@typebot\.io/blocks-integrations/httpRequest/schema' rg --type tsx '@typebot\.io/blocks-integrations/httpRequest/schema'Length of output: 4977
Script:
#!/bin/bash # Description: Check for any remaining imports from the old webhook schema path # and new imports from the httpRequest schema path in TypeScript files. echo "Checking for remaining imports from webhook schema:" rg --type typescript '@typebot\.io/blocks-integrations/webhook/schema' rg --type typescriptreact '@typebot\.io/blocks-integrations/webhook/schema' echo "Checking for new imports from httpRequest schema:" rg --type typescript '@typebot\.io/blocks-integrations/httpRequest/schema' rg --type typescriptreact '@typebot\.io/blocks-integrations/httpRequest/schema'Length of output: 681
Script:
#!/bin/bash # Description: Check for any remaining imports from the old webhook schema path # and new imports from the httpRequest schema path in TypeScript files. echo "Checking for remaining imports from webhook schema:" rg '@typebot\.io/blocks-integrations/webhook/schema' -g '*.ts' -g '*.tsx' echo "Checking for new imports from httpRequest schema:" rg '@typebot\.io/blocks-integrations/httpRequest/schema' -g '*.ts' -g '*.tsx'Length of output: 4807
packages/blocks/integrations/src/schema.ts (2)
Line range hint
22-32: LGTM! Consistent usage ofhttpBlockSchemasin V5 and V6 schemas.The usage of
httpBlockSchemas.v5andhttpBlockSchemas.v6in their respective schema definitions remains unchanged. This consistency ensures backward compatibility and smooth integration of the new HTTP request functionality.Also applies to: 34-44
Line range hint
1-46: Summary: Minimal changes align with PR objectives.The changes in this file are minimal and focused, primarily involving the update of the import statement for
httpBlockSchemas. This change aligns with the PR objective of adding a webhook block and suggests a broader refactoring of HTTP-related functionality. The consistent usage ofhttpBlockSchemasin both V5 and V6 schemas indicates that backward compatibility is maintained.To ensure the changes are consistent across the codebase, please run the following script:
#!/bin/bash # Description: Check for any remaining references to the old webhook schema # Test: Search for any remaining imports from the old webhook schema rg --type typescript 'import.*from.*"./webhook/schema"'This will help identify any other files that might need updating as part of this refactoring.
apps/builder/src/features/blocks/integrations/makeCom/components/MakeComSettings.tsx (1)
3-3: LGTM! Verify consistency of import path changes across the project.The import path changes for
HttpRequesttype andHttpRequestAdvancedConfigFormcomponent reflect a project restructuring, moving fromwebhooktohttpRequestdirectory. This change improves the organization of the codebase by separating HTTP request functionality from webhook-specific functionality.To ensure consistency across the project, please run the following script:
Also applies to: 6-6
✅ Verification successful
✅ Import paths have been consistently updated across the project.
All instances of
HttpRequestandHttpRequestAdvancedConfigFormnow correctly reference the newhttpRequestdirectory. No residual imports from the oldwebhookpaths were found.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all imports of HttpRequest and HttpRequestAdvancedConfigForm have been updated consistently. # Test 1: Check for any remaining imports from the old webhook path echo "Checking for old webhook imports:" rg --type typescript 'from.*@typebot\.io/blocks-integrations/webhook/schema' # Test 2: Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for old HttpRequestAdvancedConfigForm imports:" rg --type typescript 'from.*\.\.\/\.\.\/webhook/components/HttpRequestAdvancedConfigForm' # Test 3: Verify new imports are used consistently echo "Checking for new httpRequest imports:" rg --type typescript 'from.*@typebot\.io/blocks-integrations/httpRequest/schema' rg --type typescript 'from.*\.\.\/\.\.\/httpRequest/components/HttpRequestAdvancedConfigForm' echo "If any of the above searches return results, please review those files to ensure consistent import updates."Length of output: 1217
Script:
#!/bin/bash # Description: Verify that all imports of HttpRequest and HttpRequestAdvancedConfigForm have been updated consistently. # Test 1: Check for any remaining imports from the old webhook path echo "Checking for old webhook imports:" rg -g "*.ts" -g "*.tsx" 'from\s+["@]typebot\.io/blocks-integrations/webhook/schema["]' # Test 2: Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for old HttpRequestAdvancedConfigForm imports:" rg -g "*.ts" -g "*.tsx" 'from\s+\.\.\/\.\.\/webhook\/components\/HttpRequestAdvancedConfigForm["]' # Test 3: Verify new imports are used consistently echo "Checking for new httpRequest imports:" rg -g "*.ts" -g "*.tsx" 'from\s+["@]typebot\.io/blocks-integrations/httpRequest/schema["]' rg -g "*.ts" -g "*.tsx" 'from\s+\.\.\/\.\.\/httpRequest\/components\/HttpRequestAdvancedConfigForm["]' echo "If any of the above searches return results, please review those files to ensure consistent import updates."Length of output: 1199
Script:
#!/bin/bash # Description: Verify that all imports of HttpRequest and HttpRequestAdvancedConfigForm have been updated consistently. # Test 1: Check for any remaining imports from the old webhook path echo "Checking for old webhook imports:" rg -g "*.ts" -g "*.tsx" 'from\s+["@]typebot\.io/blocks-integrations/webhook/schema"' # Test 2: Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for old HttpRequestAdvancedConfigForm imports:" rg -g "*.ts" -g "*.tsx" 'from\s+\.\.\/\.\.\/webhook\/components\/HttpRequestAdvancedConfigForm"' # Test 3: Verify new imports are used consistently echo "Checking for new httpRequest imports:" rg -g "*.ts" -g "*.tsx" 'from\s+["@]typebot\.io/blocks-integrations/httpRequest/schema"' rg -g "*.ts" -g "*.tsx" 'from\s+\.\.\/\.\.\/httpRequest\/components\/HttpRequestAdvancedConfigForm"' echo "If any of the above searches return results, please review those files to ensure consistent import updates."Length of output: 1187
Script:
#!/bin/bash # Description: Verify that all imports of HttpRequest and HttpRequestAdvancedConfigForm have been updated consistently. # Test 1: Check for any remaining imports from the old webhook path echo "Checking for old webhook imports:" rg -g "*.ts" -g "*.tsx" 'from\s+["'\'']@typebot\.io/blocks-integrations/webhook/schema["'\'']' # Test 2: Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for old HttpRequestAdvancedConfigForm imports:" rg -g "*.ts" -g "*.tsx" 'from\s+\.\./\.\./webhook/components/HttpRequestAdvancedConfigForm["'\'']' # Test 3: Verify new imports are used consistently echo "Checking for new httpRequest imports:" rg -g "*.ts" -g "*.tsx" 'from\s+["'\'']@typebot\.io/blocks-integrations/httpRequest/schema["'\'']' rg -g "*.ts" -g "*.tsx" 'from\s+\.\./\.\./httpRequest/components/HttpRequestAdvancedConfigForm["'\'']' echo "If any of the above searches return results, please review those files to ensure consistent import updates."Length of output: 5341
Script:
#!/bin/bash # Description: Verify that all imports of HttpRequest and HttpRequestAdvancedConfigForm have been updated consistently. # Test 1: Check for any remaining imports from the old webhook path echo "Checking for old webhook imports:" rg -g "*.ts" -g "*.tsx" "from\s+[@\"]typebot\.io/blocks-integrations/webhook/schema[@\"]" # Test 2: Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for old HttpRequestAdvancedConfigForm imports:" rg -g "*.ts" -g "*.tsx" "from\s+\.\./\.\./webhook/components/HttpRequestAdvancedConfigForm[@\"]" # Test 3: Verify new imports are used consistently echo "Checking for new httpRequest imports:" rg -g "*.ts" -g "*.tsx" "from\s+[@\"]typebot\.io/blocks-integrations/httpRequest/schema[@\"]" rg -g "*.ts" -g "*.tsx" "from\s+\.\./\.\./httpRequest/components/HttpRequestAdvancedConfigForm[@\"]" echo "If any of the above searches return results, please review those files to ensure consistent import updates."Length of output: 891
apps/builder/src/features/blocks/integrations/zapier/components/ZapierSettings.tsx (2)
9-9: LGTM! Verify the new location of the HttpRequestAdvancedConfigForm component.The import path for
HttpRequestAdvancedConfigFormhas been updated, which is consistent with the previous import change. This reflects the restructuring from webhook-related to HTTP request-related organization.To ensure the component exists at the new location, please run the following script:
#!/bin/bash # Description: Verify the existence of HttpRequestAdvancedConfigForm in the new location # Test: Check if the file exists in the new location. Expect: File found. fd --type file --full-path '.*httpRequest/components/HttpRequestAdvancedConfigForm\.tsx$'
6-6: LGTM! Verify the impact of this import change across the codebase.The import path for
HttpRequestandHttpRequestBlocktypes has been updated, which appears to be part of a module restructuring. This change is appropriate and doesn't affect the usage within this file.To ensure this change doesn't introduce issues elsewhere, please run the following script to check for any remaining imports using the old path:
✅ Verification successful
All import paths updated successfully. No remaining imports from the old webhook schema path detected.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining imports using the old webhook schema path # Test: Search for imports from the old path. Expect: No results. rg --type typescript 'from.*@typebot\.io/blocks-integrations/webhook/schema'Length of output: 194
apps/viewer/src/pages/api/typebots/[typebotId]/webhookSteps.ts (2)
2-2: LGTM: Import statement forisHttpRequestBlockadded correctly.The import of
isHttpRequestBlockfrom "@typebot.io/blocks-core/helpers" is correctly added and aligns with the changes in the filtering logic.
Line range hint
26-33: Approved: Filtering logic updated, but clarification needed.The change from
isWebhookBlocktoisHttpRequestBlockand the updated filtering logic look good. This modification aligns with the PR objective of adding a webhook block. However, I have a few points for consideration:
- Could you clarify how this change relates to the Wait block mentioned in the linked issue Add Webhook block #1531?
- Consider adding a comment explaining the purpose of this filtering, especially the check for undefined URLs in associated webhooks.
- It might be helpful to update any relevant documentation to reflect this change in terminology from "webhook blocks" to "HTTP request blocks".
To ensure consistency across the codebase, let's check for any remaining uses of
isWebhookBlock:✅ Verification successful
Verified: No remaining uses of
isWebhookBlockfound.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining uses of isWebhookBlock rg "isWebhookBlock" --type typescriptLength of output: 72
Script:
#!/bin/bash # Description: Check for any remaining uses of isWebhookBlock in TypeScript files rg "isWebhookBlock" --glob "*.ts" --glob "*.tsx"Length of output: 48
apps/viewer/src/pages/api/typebots/[typebotId]/webhookBlocks.ts (2)
25-25: Approve change in block filtering logic and verify impact.The modification from
isWebhookBlock(block)toisHttpRequestBlock(block)is consistent with the earlier import changes. This alteration reflects an update in how blocks are identified and processed within the system.To ensure this change doesn't introduce any unintended side effects, please verify:
- The
isHttpRequestBlockfunction correctly identifies all relevant blocks.- No webhook blocks are unintentionally excluded from processing.
Run the following script to check for any remaining references to
isWebhookBlockin the codebase:#!/bin/bash # Description: Find any remaining references to isWebhookBlock in the codebase. echo "Files still using isWebhookBlock function:" rg --type typescript "isWebhookBlock\("If any results are returned, those files may need to be updated as well.
2-3: Verify impact of import changes and update related files.The changes in import statements suggest a shift from webhook blocks to HTTP request blocks. This modification might have broader implications:
- The change from
isWebhookBlocktoisHttpRequestBlockindicates a terminology or functionality update.- The new import path for
HttpRequestBlocksuggests a project architecture change.Please run the following script to identify other files that might need updates:
Ensure that all related files are updated to maintain consistency across the project.
✅ Verification successful
Import changes have been successfully verified and no residual usages found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find files that still use the old imports and might need updates. echo "Files still using isWebhookBlock:" rg --type typescript "import.*isWebhookBlock.*from.*@typebot\.io/blocks-core/helpers" echo "\nFiles still using the old HttpRequestBlock import path:" rg --type typescript "import.*HttpRequestBlock.*from.*@typebot\.io/blocks-integrations/webhook/schema"Length of output: 265
Script:
#!/bin/bash # Description: Find files that still use the old imports and might need updates. echo "Files still using isWebhookBlock:" rg 'import.*isWebhookBlock.*from.*@typebot\.io/blocks-core/helpers' --type-add 'ts=*.ts' --type ts echo "\nFiles still using the old HttpRequestBlock import path:" rg 'import.*HttpRequestBlock.*from.*@typebot\.io/blocks-integrations/webhook/schema' --type-add 'ts=*.ts' --type tsLength of output: 540
Script:
#!/bin/bash # Description: Find files that still use the old imports and might need updates. echo "Files still using isWebhookBlock:" rg 'import.*isWebhookBlock.*from.*@typebot\.io/blocks-core/helpers' --type-add 'ts:*.ts' --type ts echo "\nFiles still using the old HttpRequestBlock import path:" rg 'import.*HttpRequestBlock.*from.*@typebot\.io/blocks-integrations/webhook/schema' --type-add 'ts:*.ts' --type tsLength of output: 420
packages/bot-engine/src/executeLogic.ts (2)
12-12: LGTM: New import for webhook block execution.The import statement for
executeWebhookBlockis correctly placed and follows the existing pattern for other block types. This import is necessary for the new webhook functionality being added.
39-40: Verify the parameters for executeWebhookBlock.The new case for
LogicBlockType.WEBHOOKis correctly implemented and follows the existing pattern. However, unlike some other cases (e.g., SET_VARIABLE, CONDITION), it doesn't pass thestateparameter toexecuteWebhookBlock.Please confirm if this is intentional. If
stateis needed, consider updating the function call:- return executeWebhookBlock(block); + return executeWebhookBlock(state, block);To verify the implementation, let's check the
executeWebhookBlockfunction:✅ Verification successful
Parameters for
executeWebhookBlockare correctly passed with only theblockparameter.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the parameters of executeWebhookBlock function # Test: Check the function signature of executeWebhookBlock ast-grep --lang typescript --pattern 'export const executeWebhookBlock = ($_) => $_'Length of output: 86
Script:
#!/bin/bash # Description: Verify the parameters of executeWebhookBlock function with an updated pattern # Test: Check the function signature of executeWebhookBlock with different declaration styles ast-grep --lang typescript --pattern 'export (const|function) executeWebhookBlock =? \(([^\)]*)\) =>? \{?[^}]*\}'Length of output: 460
Script:
#!/bin/bash # Description: Search for all occurrences of executeWebhookBlock in the codebase rg 'executeWebhookBlock' --type tsLength of output: 487
Script:
#!/bin/bash # Description: Retrieve the full function definition of executeWebhookBlock # Search for the function definition and include 3 lines of context after the match rg 'export const executeWebhookBlock =' --type ts -A 5 packages/bot-engine/src/blocks/logic/webhook/executeWebhookBlock.tsLength of output: 283
apps/builder/src/features/blocks/integrations/httpRequest/api/getResultExample.ts (1)
Line range hint
5-20: Overall impact: Generalization towards HTTP requestsThe changes in this file represent a shift from webhook-specific handling to more general HTTP request processing. This aligns well with the PR objectives of adding a webhook block and addresses the linked issue #1531.
While the core logic of the
getResultExamplefunction remains unchanged, its context has been broadened. This approach allows for more flexible handling of various HTTP requests, including webhooks.To ensure these changes haven't inadvertently affected existing functionality:
- Verify that all existing webhook functionality still works as expected.
- Test the new HTTP request block thoroughly, ensuring it handles both webhook and non-webhook scenarios correctly.
- Update any documentation or user guides to reflect this change from "webhook" to "HTTP request" terminology.
Run the following script to identify any remaining references to the old webhook module that might need updating:
✅ Verification successful
All references to the old webhook module have been successfully removed.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find any remaining references to the old webhook module rg --type typescript "bot-engine/blocks/integrations/webhook"Length of output: 96
Script:
#!/bin/bash # Description: Find any remaining references to the old webhook module rg --type ts "bot-engine/blocks/integrations/webhook"Length of output: 53
Script:
#!/bin/bash # Description: Find any remaining references to the old webhook module using a glob pattern rg "bot-engine/blocks/integrations/webhook" --glob "*.ts"Length of output: 57
apps/builder/src/features/blocks/integrations/pabbly/components/PabblyConnectSettings.tsx (2)
Line range hint
9-72: LGTM! Component logic remains intact.The
PabblyConnectSettingscomponent's functionality has been preserved despite the changes in import statements. This suggests that the refactoring of HTTP request and webhook-related code has been done in a backwards-compatible manner, which is a good practice.
4-4: LGTM! Verify consistency of import changes across the codebase.The changes in import statements reflect a refactoring of the codebase structure, moving from webhook-specific imports to more general HTTP request imports. This change appears to be an improvement in code organization.
To ensure these changes are consistent across the codebase, please run the following script:
This script will help identify any inconsistencies in import statements across the codebase, ensuring that the refactoring has been applied uniformly.
Also applies to: 7-7
✅ Verification successful
Shell Script Errors Detected. Please run the corrected script below to verify import consistency across the codebase.
Shell Script Errors Detected. Please run the corrected script below to verify import consistency across the codebase.
Verified! Import changes are consistent across the codebase.
All import statements have been successfully updated from the old webhook schema to the new HTTP request schema, ensuring consistency and improved code organization.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the consistency of import changes across the codebase # Check for any remaining imports from the old webhook schema echo "Checking for any remaining imports from the old webhook schema:" rg --type typescript 'from.*@typebot\.io/blocks-integrations/webhook/schema' # Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for any remaining imports of HttpRequestAdvancedConfigForm from the old path:" rg --type typescript 'from.*\.\.\/\.\.\/webhook\/components\/HttpRequestAdvancedConfigForm' # Check for the new imports to ensure they are used consistently echo "Checking for the new HttpRequest import:" rg --type typescript 'from.*@typebot\.io/blocks-integrations/httpRequest/schema' echo "Checking for the new HttpRequestAdvancedConfigForm import:" rg --type typescript 'from.*\.\.\/\.\.\/httpRequest\/components\/HttpRequestAdvancedConfigForm'Length of output: 1255
Script:
#!/bin/bash # Description: Verify the consistency of import changes across the codebase # Check for any remaining imports from the old webhook schema echo "Checking for any remaining imports from the old webhook schema:" rg 'from\s+["@typebot.io/blocks-integrations/webhook/schema"]' --glob '*.ts' # Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for any remaining imports of HttpRequestAdvancedConfigForm from the old path:" rg 'from\s+\.\./\.\./webhook/components/HttpRequestAdvancedConfigForm' --glob '*.ts' # Check for the new HttpRequest import to ensure they are used consistently echo "Checking for the new HttpRequest import:" rg 'from\s+["@typebot.io/blocks-integrations/httpRequest/schema"]' --glob '*.ts' # Check for the new HttpRequestAdvancedConfigForm import to ensure consistency echo "Checking for the new HttpRequestAdvancedConfigForm import:" rg 'from\s+\.\./\.\./httpRequest/components/HttpRequestAdvancedConfigForm' --glob '*.ts'Length of output: 1245
Script:
#!/bin/bash # Description: Verify the consistency of import changes across the codebase # Check for any remaining imports from the old webhook schema echo "Checking for any remaining imports from the old webhook schema:" rg 'from\s+"@typebot\.io/blocks-integrations/webhook/schema"' --glob '*.ts' # Check for any remaining imports of HttpRequestAdvancedConfigForm from the old path echo "Checking for any remaining imports of HttpRequestAdvancedConfigForm from the old path:" rg 'from\s+\.\./\.\./webhook/components/HttpRequestAdvancedConfigForm' --glob '*.ts' # Check for the new HttpRequest import to ensure they are used consistently echo "Checking for the new HttpRequest import:" rg 'from\s+"@typebot\.io/blocks-integrations/httpRequest/schema"' --glob '*.ts' # Check for the new HttpRequestAdvancedConfigForm import to ensure consistency echo "Checking for the new HttpRequestAdvancedConfigForm import:" rg 'from\s+\.\./\.\./httpRequest/components/HttpRequestAdvancedConfigForm' --glob '*.ts'Length of output: 3577
packages/bot-engine/src/saveStateToDatabase.ts (3)
22-22: LGTM: Function parameter destructuring updatedThe inclusion of
isReplyingin the destructuredsessionparameter is consistent with thePropstype update and allows for proper handling of the new state information within the function.
Line range hint
1-87: Overall assessment: Changes effectively implement isReplying stateThe modifications in this file successfully integrate the new
isReplyingstate into the session management logic. The changes are consistent, well-implemented, and align with the PR objectives of enhancing webhook functionality.Key points:
- The
Propstype has been updated to include theisReplyingproperty.- The
saveStateToDatabasefunction now handles theisReplyingstate in both session updates and creations.- Proper default values are set to ensure consistent behavior.
These changes provide a solid foundation for implementing webhook-related features, particularly in managing the state of ongoing replies.
To ensure the changes are properly integrated, let's verify the usage of
createSessionandupdateSessionfunctions:#!/bin/bash # Description: Check for any usages of createSession and updateSession functions # Test: Search for createSession function calls rg --type typescript -A 5 'createSession\(' # Test: Search for updateSession function calls rg --type typescript -A 5 'updateSession\('
11-11: LGTM: Props type updated to include isReplyingThe addition of
isReplyingto thesessionproperty in thePropstype is a good enhancement. It allows for better state management by tracking whether a session is currently replying.To ensure this change doesn't introduce any inconsistencies, let's verify if all usages of this type have been updated accordingly:
packages/deprecated/bot-engine/src/features/blocks/integrations/webhook/utils/executeWebhookBlock.ts (2)
Line range hint
1-70: Summary of the review:
- The import path change for
HttpRequestBlockhas been approved.- The rest of the code remains unchanged and functions as expected.
- Suggestions for code improvements have been provided, including:
- Using type narrowing for better type safety
- Extracting the status code check into a separate function
- Using optional chaining for safer property access
Overall, the changes look good, and the additional suggestions can further improve the code quality.
3-3: LGTM! Verify related files for consistency.The import path change for
HttpRequestBlocklooks good and is consistent with the function's usage. This change suggests a refactoring of the codebase, moving theHttpRequestBlocktype to a more generichttpRequestmodule.To ensure consistency across the codebase, please run the following script to check for any other occurrences of the old import path:
apps/builder/src/features/blocks/logic/webhook/webhook.spec.ts (1)
1-9: LGTM: Imports and initial setup are well-structured.The import statements are appropriate for the test suite, and creating a unique
typebotIdensures proper test isolation.packages/bot-engine/src/executeIntegration.ts (3)
7-7: LGTM: New import added correctly.The import for
executeHttpRequestBlockis correctly placed and consistent with the project structure. This import is necessary for the changes made in theexecuteIntegrationfunction.
Line range hint
1-58: Overall, the changes look good and align with the PR objectives.The modifications to
executeIntegration.tssuccessfully implement the new webhook block functionality by consolidating webhook and HTTP request processing. The code is well-structured and consistent with the existing patterns in the file.Key improvements:
- Addition of
executeHttpRequestBlockfor handling various integration types.- Consolidation of ZAPIER, MAKE_COM, and PABBLY_CONNECT types with HTTP request functionality.
- Implementation of a new HTTP_REQUEST type with flexible timeout handling.
Consider addressing the minor suggestions in the previous comments to further improve code readability and consistency.
40-45: LGTM: New HTTP_REQUEST type handled correctly.The implementation for the new HTTP_REQUEST type looks good. It uses
executeHttpRequestBlockwith a flexible timeout handling based on theCHAT_API_TIMEOUTenvironment variable.Could you clarify why the
startTimeShouldBeUpdatedflag is not set for this type, unlike other integration types? Is this intentional?To verify the usage of
CHAT_API_TIMEOUT, let's check its definition:✅ Verification successful
Verified:
CHAT_API_TIMEOUTis properly defined within the codebase and used consistently across relevant modules.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the definition and usage of CHAT_API_TIMEOUT # Expected result: Find the definition of CHAT_API_TIMEOUT in environment files # Search for CHAT_API_TIMEOUT in .env files rg 'CHAT_API_TIMEOUT' --type env # Search for CHAT_API_TIMEOUT in TypeScript files rg 'CHAT_API_TIMEOUT' --type typescriptLength of output: 135
Script:
#!/bin/bash # Description: Verify the definition of CHAT_API_TIMEOUT in environment files # Expected result: Find the definition of CHAT_API_TIMEOUT in .env files # Search for CHAT_API_TIMEOUT in .env files rg 'CHAT_API_TIMEOUT' --glob '*.env' # Description: Verify the usage of CHAT_API_TIMEOUT in TypeScript files # Expected result: Find all instances where CHAT_API_TIMEOUT is used # Search for CHAT_API_TIMEOUT in TypeScript files rg 'CHAT_API_TIMEOUT' --glob '*.ts'Length of output: 827
apps/builder/src/features/blocks/integrations/httpRequest/api/listHttpRequestBlocks.ts (6)
62-73: LGTM! Variable names updated consistently.The variable names have been correctly updated from
webhookBlockstohttpRequestBlocks, maintaining consistency with the overall changes. The type definition for the reduced array has also been appropriately updated.
74-74: LGTM! Filter function updated correctly.The filter function has been correctly updated from
isWebhookBlocktoisHttpRequestBlock, maintaining consistency with the import statement change and the overall refactoring.
76-76: LGTM! Spread operator updated consistently.The spread operator now correctly uses
httpRequestBlock, maintaining consistency with the earlier variable name updates. This ensures that the accumulated results are properly spread into the new array.
12-21: LGTM! Verify the OpenAPI path update.The procedure name and OpenAPI metadata have been correctly updated to reflect the change from webhook to HTTP request blocks. The changes are comprehensive and consistent.
To ensure the OpenAPI path has been updated correctly, run the following script:
#!/bin/bash # Description: Verify the OpenAPI path update in other files. # Test: Search for any remaining references to the old path. rg --type typescript '/v1/typebots/{typebotId}/webhookBlocks'
35-35: LGTM! Verify the IntegrationBlockType enum update.The IntegrationBlockType enum value has been correctly updated from WEBHOOK to HTTP_REQUEST, consistent with the overall changes.
To ensure the IntegrationBlockType enum has been updated correctly in its definition file, run the following script:
#!/bin/bash # Description: Verify the IntegrationBlockType enum update in its definition file. # Test: Search for the HTTP_REQUEST enum value in the constants file. rg --type typescript 'HTTP_REQUEST' $(fd -t f 'constants.ts' -p '**/blocks-integrations')
4-4: LGTM! Verify the imported function name.The import statement has been correctly updated to reflect the change from webhook to HTTP request blocks.
To ensure the imported function name is correct, run the following script:
✅ Verification successful
LGTM! The
isHttpRequestBlockfunction is correctly imported and exists in the@typebot.io/blocks-core/helpersmodule.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence of the isHttpRequestBlock function in the imported module. # Test: Search for the function definition in the @typebot.io/blocks-core/helpers module. rg --type typescript 'export function isHttpRequestBlock' $(fd -t f 'index.ts' -p '**/blocks-core/helpers')Length of output: 390
Script:
#!/bin/bash # Description: Search for the definition of 'isHttpRequestBlock' across all TypeScript files. # Using ripgrep with the correct file type identifier. rg --type ts 'export function isHttpRequestBlock' # Alternatively, using ast-grep for a more precise search. # ast-grep --lang typescript --pattern 'export function isHttpRequestBlock($_, $_) { $$$ }'Length of output: 51
Script:
#!/bin/bash # Description: Search for any occurrence of 'isHttpRequestBlock' across the entire codebase. # Using ripgrep without restricting to export declarations. rg 'isHttpRequestBlock'Length of output: 2553
packages/blocks/integrations/src/httpRequest/schema.ts (1)
72-72: Approve change and suggest documentation updatesThe change from
IntegrationBlockType.WEBHOOKtoIntegrationBlockType.HTTP_REQUESTaligns with the PR objectives of adding webhook capabilities. This renaming likely improves clarity and consistency in the codebase.To ensure consistency and catch any potential issues, please run the following verification script:
Consider the following suggestions:
- Update any relevant documentation to reflect this change from WEBHOOK to HTTP_REQUEST.
- Add a comment explaining the rationale behind this change and its implications.
- If not already done, create a migration plan for any existing code that might be affected by this type change.
✅ Verification successful
Change Verified: IntegrationBlockType Updated
The change from
IntegrationBlockType.WEBHOOKtoIntegrationBlockType.HTTP_REQUESThas been successfully verified. All references toWEBHOOKhave been removed, andHTTP_REQUESTis used consistently across the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for any remaining references to IntegrationBlockType.WEBHOOK and verify consistent usage of IntegrationBlockType.HTTP_REQUEST # Search for any remaining WEBHOOK references echo "Searching for remaining WEBHOOK references:" rg --type typescript "IntegrationBlockType\.WEBHOOK" # Verify consistent usage of HTTP_REQUEST echo "Verifying consistent usage of HTTP_REQUEST:" rg --type typescript "IntegrationBlockType\.HTTP_REQUEST" # Check for any TODO or FIXME comments related to this change echo "Checking for related TODO or FIXME comments:" rg --type typescript "(TODO|FIXME).*WEBHOOK"Length of output: 559
Script:
#!/bin/bash # Description: Check for any remaining references to IntegrationBlockType.WEBHOOK and verify consistent usage of IntegrationBlockType.HTTP_REQUEST # Search for any remaining WEBHOOK references echo "Searching for remaining WEBHOOK references:" rg "IntegrationBlockType\.WEBHOOK" # Verify consistent usage of HTTP_REQUEST echo "Verifying consistent usage of HTTP_REQUEST:" rg "IntegrationBlockType\.HTTP_REQUEST" # Check for any TODO or FIXME comments related to this change echo "Checking for related TODO or FIXME comments:" rg "(TODO|FIXME).*WEBHOOK"Length of output: 1712
apps/builder/src/features/blocks/integrations/httpRequest/api/unsubscribeHttpRequest.ts (6)
50-50: LGTM! Consistent variable naming and error messages.The changes to variable names and error messages are consistent with the refactoring from webhook to HTTP request. This maintains clarity and consistency throughout the code.
Also applies to: 54-54, 57-57
71-71: LGTM! Consistent nested object references.The updates to the nested object references are consistent with the variable renaming. The structure of the options object is maintained, ensuring compatibility with existing data.
Also applies to: 73-73
97-97: LGTM! Consistent error message.The error message has been updated to use the new "HTTP request block" terminology, maintaining consistency with the rest of the changes.
Line range hint
1-105: Overall, the changes look good and consistent.The refactoring from "webhook" to "HTTP request" has been implemented consistently throughout the file. The changes include updates to import statements, function names, variable names, error messages, and database interaction logic. The code maintains backward compatibility with version 6 of the typebot.
Key points:
- The function name and OpenAPI metadata have been updated to reflect the new terminology.
- The logic for handling different block structures has been preserved.
- Error messages and variable names have been updated for consistency.
The changes improve the clarity and consistency of the code while maintaining its functionality. The suggestions for additional documentation and clarification, if implemented, will further enhance the code's maintainability.
12-12: LGTM! Verify external references to this function.The function name and OpenAPI metadata changes are consistent with the refactoring from webhook to HTTP request. These changes improve the clarity and consistency of the API.
Run the following script to check for any remaining references to the old function name:
#!/bin/bash # Description: Check for any remaining references to the old function name rg "unsubscribeWebhook" --type typescriptAlso applies to: 18-19
4-4: LGTM! Verify import paths for consistency.The import changes from webhook to HTTP request are consistent with the refactoring. However, it's important to ensure that the import paths are correct and that these changes are reflected in the imported modules.
Run the following script to verify the import paths:
Also applies to: 6-6
✅ Verification successful
Import paths verified and consistent. No issues found.
The import changes from
WebhooktoHttpRequestare correctly reflected in the codebase. BothisHttpRequestBlockandHttpRequestBlockare properly exported and imported without any discrepancies.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the existence and content of the imported modules # Test 1: Check if the imported helper exists ast-grep --lang typescript --pattern 'export const isHttpRequestBlock' # Test 2: Check if the imported type exists ast-grep --lang typescript --pattern 'export type HttpRequestBlock'Length of output: 1118
Script:
#!/bin/bash # Description: Refine the pattern to verify the existence of the exported type HttpRequestBlock ast-grep --lang typescript --pattern 'export type HttpRequestBlock = $_'Length of output: 197
packages/embeds/js/src/utils/executeClientSideActions.ts (3)
3-3: LGTM: New import for HTTP request execution.The import for
executeHttpRequestis correctly placed and consistent with other imports. This addition supports the new HTTP request functionality implemented in this file.
13-13: LGTM: New import for webhook listening.The import for
listenForWebhookis correctly placed and consistent with other imports. This addition supports the new webhook listening functionality implemented in this file.
Line range hint
1-102: Summary: Successful implementation of HTTP requests and webhook listening.The changes in this file effectively implement new functionality for executing HTTP requests and listening for webhooks. The new imports and conditions are well-integrated into the existing structure of the
executeClientSideActionfunction. These additions enhance the capabilities of the client-side actions, allowing for more versatile interactions with external systems.A minor suggestion for consistency has been made regarding the
listenForWebhookcondition. Overall, these changes successfully address the objectives outlined in the PR, particularly the addition of webhook functionality as mentioned in issue #1531.To ensure that the removal of the previous webhook implementation doesn't cause any regressions, please run the following verification script:
This script will help verify that the old webhook implementation has been completely replaced and there are no lingering references that might cause issues.
apps/builder/src/features/graph/helpers/getHelpDocUrl.ts (1)
54-55: LGTM! Verify the implementation of the new HTTP_REQUEST block type.The addition of the
IntegrationBlockType.HTTP_REQUESTcase is appropriate and provides the correct documentation URL. This change suggests that a new integration block type for HTTP requests has been introduced to the system.To ensure consistency, please verify the implementation of the new HTTP_REQUEST block type:
apps/docs/editor/blocks/integrations/http-request.mdx (2)
44-44: Image path update looks good.The change from "webhook" to "http-request" in the image path accurately reflects the document's focus on HTTP requests.
53-53: Image path update is consistent.The change from "webhook" to "http-request" in this image path is consistent with the previous update and maintains the document's focus on HTTP requests.
apps/builder/src/features/editor/components/BlockLabel.tsx (3)
45-45: Improved type safety for getBubbleBlockLabel functionThe change from
Record<BubbleBlockType, string>to{ [key in BubbleBlockType]: string }enhances type safety. This mapped type ensures that all keys in BubbleBlockType are explicitly covered, reducing the risk of missing or extraneous keys.
55-55: Consistent type safety improvement for getInputBlockLabel functionThe return type change to
{ [key in InputBlockType]: string }is consistent with the previous function's improvement. This change maintains type safety across the codebase and ensures all InputBlockType keys are accounted for.
85-90: Type safety improvement and HTTP_REQUEST replacing WEBHOOKThe return type change to
{ [key in IntegrationBlockType]: string }is consistent with previous improvements, enhancing type safety.The replacement of WEBHOOK with HTTP_REQUEST is noted:
[IntegrationBlockType.HTTP_REQUEST]: "HTTP request",This change suggests a refactoring or renaming of this integration type. However, like the WEBHOOK label in the previous function, the HTTP_REQUEST label is hardcoded in English.
Consider using the translation function for the HTTP_REQUEST label to maintain consistency:
[IntegrationBlockType.HTTP_REQUEST]: t("editor.sidebarBlock.httpRequest.label"),Don't forget to add the corresponding translation key to your localization files.
To ensure consistency across the codebase, let's verify if there are any remaining references to the old WEBHOOK integration type:
packages/bot-engine/src/schemas/clientSideAction.ts (2)
2-2: LGTM: Import statement updated correctly.The import statement for
executableHttpRequestSchemahas been updated to reflect the changes in the schema structure. This change is consistent with the renaming of the webhook action to an HTTP request action.
Line range hint
1-177: Overall assessment: Changes improve schema flexibility and align with PR objectives.The modifications to this file successfully implement the new webhook functionality as outlined in the PR objectives. The changes broaden the HTTP request capabilities and introduce a new action for webhook listening, enhancing the overall flexibility of the client-side action schema.
Key improvements:
- Renamed "webhookToExecute" to "httpRequestToExecute" for broader applicability.
- Added a new "listenForWebhook" action type.
These changes are well-implemented and maintain the consistency of the schema structure. They effectively address the requirements mentioned in issue #1531 by adding webhook-related functionality to the system.
packages/blocks/core/src/helpers.ts (3)
70-70: LGTM! Consistent with function renaming.The addition of
IntegrationBlockType.HTTP_REQUESTto the array of checked block types is consistent with the renaming of the function and the shift from webhook to HTTP request. This change ensures that the function will correctly identify HTTP request blocks of the new type while maintaining checks for existing integration types.
Line range hint
68-74: LGTM! Verify usage across the codebase.The function has been correctly renamed from
isWebhookBlocktoisHttpRequestBlock, and its implementation has been updated to check forIntegrationBlockType.HTTP_REQUESTinstead ofIntegrationBlockType.WEBHOOK. This change aligns with the updated import and reflects a shift from the specific concept of a webhook to the more general concept of an HTTP request.To ensure this change is consistently applied throughout the codebase, please run the following script:
#!/bin/bash # Description: Check for any remaining usage of isWebhookBlock and IntegrationBlockType.WEBHOOK # Test 1: Search for any remaining usage of isWebhookBlock rg --type typescript 'isWebhookBlock' # Test 2: Search for any remaining usage of IntegrationBlockType.WEBHOOK rg --type typescript 'IntegrationBlockType\.WEBHOOK' # Note: If either of these commands returns any results, those occurrences may need to be updated to reflect the new naming and type.
13-13: LGTM! Verify impact on other imports.The import statement has been correctly updated to reflect the new location of the HttpRequestBlock. This change aligns with the renaming of the isWebhookBlock function to isHttpRequestBlock.
To ensure this change doesn't break other parts of the codebase, please run the following script:
apps/builder/src/features/blocks/integrations/httpRequest/httpRequest.spec.ts (2)
84-84: LGTM! Consider reviewing test coverage.The change from "Webhook API endpoints should work" to "HTTP request API endpoints should work" appropriately broadens the scope of the test. This update is consistent with the asset file name change.
To ensure the test cases adequately cover the broader scope of HTTP requests, please review the test implementation:
#!/bin/bash # Description: Display the test implementation for manual review # Test: Show the content of the test function sed -n '/test("HTTP request API endpoints should work"/,/^});/p' apps/builder/src/features/blocks/integrations/httpRequest/httpRequest.spec.tsReview the output to confirm that the existing test cases are sufficient for testing general HTTP request functionality, not just webhooks. Consider adding or modifying test cases if necessary to cover any additional HTTP request scenarios that may not have been relevant for webhooks alone.
14-14: LGTM! Verify test data consistency.The change from "webhook.json" to "httpRequest.json" aligns well with the broader scope of HTTP requests. This update is consistent with the test case name change.
To ensure the test data is consistent with the new scope, please run the following script:
This will help identify any significant changes in the test data that might affect the test behavior.
apps/builder/src/lib/theme.ts (3)
8-8: LGTM: Import statement fortabsAnatomyadded correctly.The
tabsAnatomyimport is correctly added to the existing import statement from "@chakra-ui/anatomy". This import is necessary for creating the Tabs component configuration.
260-260: LGTM: Tabs component added to the theme components.The Tabs component is correctly added to the
componentsobject, which will include the new configuration in the theme. The placement at the end of the object is appropriate and maintains the existing structure.
Line range hint
1-276: Overall, the changes look good and are well-implemented.The addition of the Tabs component configuration enhances the theme with a consistent and flexible tabs styling. The changes are well-structured and follow the existing patterns in the file. A minor suggestion was made to improve accessibility, but otherwise, the implementation is solid and ready for integration.
apps/builder/src/features/editor/providers/typebotActions/blocks.ts (1)
9-9: LGTM! Verify impact on other files.The import statement change for
HttpRequestlooks good. It appears to be part of a refactoring to generalize HTTP request handling.To ensure consistency across the codebase, please run the following script to check for any other occurrences of the old import path:
This will help identify any files that might need updating to maintain consistency with this change.
✅ Verification successful
Import path successfully updated across the codebase.
No remaining references to the old import path were found.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other occurrences of the old import path # Test: Search for the old import path rg --type typescript '@typebot.io/blocks-integrations/webhook/schema' # Test: Verify that the new import path is used consistently rg --type typescript '@typebot.io/blocks-integrations/httpRequest/schema'Length of output: 213
Script:
#!/bin/bash # Description: Check for other occurrences of the old import path in TypeScript files # Test: Search for the old import path in .ts files rg '@typebot.io/blocks-integrations/webhook/schema' --glob '*.ts' # Test: Verify that the new import path is used consistently in .ts files rg '@typebot.io/blocks-integrations/httpRequest/schema' --glob '*.ts'Length of output: 2837
apps/builder/src/features/editor/components/BlockIcon.tsx (3)
35-35: LGTM: New import for WebhookIconThe import statement for
WebhookIconis correctly placed and follows the project's import conventions. This import is necessary for the new webhook case added later in the file.
Line range hint
1-126: Summary: Implementation of webhook block looks goodThe changes in this file successfully implement the new webhook block as a logic block and update the existing integration block. The modifications are consistent with the PR objectives and follow the existing patterns in the file.
Key points:
- The
WebhookIconis correctly imported and used for the newLogicBlockType.WEBHOOK.- The
IntegrationBlockType.WEBHOOKhas been renamed toHTTP_REQUESTwith an appropriate icon change.Please address the minor suggestions in the previous comments and verify the impact of the integration block type renaming on the rest of the codebase.
108-109: Verify the impact of renaming WEBHOOK to HTTP_REQUESTThe change from
IntegrationBlockType.WEBHOOKtoIntegrationBlockType.HTTP_REQUESTand the corresponding icon update look good. This renaming aligns with the new webhook implementation as a logic block.Please ensure that this change is consistent throughout the codebase. Run the following script to check for any remaining references to
IntegrationBlockType.WEBHOOK:✅ Verification successful
Please run the following updated script to check for any remaining references to
IntegrationBlockType.WEBHOOKand ensure thatIntegrationBlockType.HTTP_REQUESTis used consistently:
Renaming of
IntegrationBlockType.WEBHOOKtoHTTP_REQUESTVerifiedThe renaming has been successfully propagated throughout the codebase. No remaining references to
IntegrationBlockType.WEBHOOKwere found, andIntegrationBlockType.HTTP_REQUESTis used consistently across all relevant files.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for remaining references to IntegrationBlockType.WEBHOOK # Test: Search for IntegrationBlockType.WEBHOOK echo "Searching for IntegrationBlockType.WEBHOOK:" rg --type typescript "IntegrationBlockType\.WEBHOOK" # Test: Search for HTTP_REQUEST to ensure it's used consistently echo "Searching for IntegrationBlockType.HTTP_REQUEST:" rg --type typescript "IntegrationBlockType\.HTTP_REQUEST"Length of output: 388
Script:
#!/bin/bash # Description: Check for remaining references to IntegrationBlockType.WEBHOOK # Search for IntegrationBlockType.WEBHOOK in TypeScript files echo "Searching for IntegrationBlockType.WEBHOOK:" rg "IntegrationBlockType\.WEBHOOK" --glob "*.ts" --glob "*.tsx" # Search for IntegrationBlockType.HTTP_REQUEST in TypeScript files echo "Searching for IntegrationBlockType.HTTP_REQUEST:" rg "IntegrationBlockType\.HTTP_REQUEST" --glob "*.ts" --glob "*.tsx"Length of output: 1652
apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx (3)
20-20: LGTM: New imports for HTTP request and webhook components.The new import statements for
HttpRequestNodeContentandWebhookNodeContentare correctly added and align with the PR objectives of implementing a webhook block. The imports follow the existing naming conventions and file structure.Also applies to: 34-34
127-128: LGTM: New case for webhook block type.The new case for
LogicBlockType.WEBHOOKcorrectly renders theWebhookNodeContentcomponent with the block options. This implementation aligns with the PR objective of adding a webhook block and is consistent with other similar cases in the switch statement.
Line range hint
1-158: Overall assessment: Changes successfully implement the webhook block.The modifications to this file successfully implement the webhook block as per the PR objectives. The new imports, the addition of the
LogicBlockType.WEBHOOKcase, and the update to theIntegrationBlockType.HTTP_REQUESTcase are all consistent with the existing code structure and conventions.To ensure that these changes don't introduce any regressions, please run the following verification script:
This script verifies that all necessary components are imported and used correctly in the file.
✅ Verification successful
Verification Successful: All checks passed
The webhook block implementation has been successfully verified. All necessary components are correctly imported and utilized, aligning with the PR objectives and existing code structure.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify that all necessary components are imported and used correctly # Test 1: Check if HttpRequestNodeContent is imported and used if ! grep -q "import { HttpRequestNodeContent }" apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx || ! grep -q "return <HttpRequestNodeContent" apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx; then echo "Error: HttpRequestNodeContent is not properly imported or used" exit 1 fi # Test 2: Check if WebhookNodeContent is imported and used if ! grep -q "import { WebhookNodeContent }" apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx || ! grep -q "return <WebhookNodeContent" apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx; then echo "Error: WebhookNodeContent is not properly imported or used" exit 1 fi # Test 3: Check if LogicBlockType.WEBHOOK case exists if ! grep -q "case LogicBlockType.WEBHOOK:" apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx; then echo "Error: LogicBlockType.WEBHOOK case is missing" exit 1 fi # Test 4: Check if IntegrationBlockType.HTTP_REQUEST case exists if ! grep -q "case IntegrationBlockType.HTTP_REQUEST:" apps/builder/src/features/graph/components/nodes/block/BlockNodeContent.tsx; then echo "Error: IntegrationBlockType.HTTP_REQUEST case is missing" exit 1 fi echo "All checks passed successfully"Length of output: 789
apps/builder/src/features/editor/components/BlocksSideBar.tsx (1)
23-23: LGTM: New imports added for environment variables and utility function.The new imports for
envandisDefinedare appropriate for the changes made in thefilteredLogicBlockTypeslogic. They provide access to environment variables and a utility function to check if a value is defined, which are necessary for the new conditional logic.Also applies to: 25-25
apps/builder/src/features/graph/components/nodes/block/SettingsPopoverContent.tsx (4)
15-15: LGTM: New imports align with PR objectives.The addition of
HttpRequestSettingsandWebhookSettingsimports aligns well with the PR objective of adding a webhook block. These changes suggest a proper separation of concerns between HTTP requests and webhook functionality.Also applies to: 29-29
Line range hint
1-364: Summary: Webhook block successfully implemented.The changes in this file successfully implement the webhook block functionality as outlined in the PR objectives. The modifications include:
- Adding necessary imports for HTTP requests and webhook settings.
- Refactoring HTTP request handling.
- Implementing webhook functionality as a logic block.
These changes are well-structured and consistent with the existing codebase. To ensure a smooth integration, please perform the following final verifications:
- Test the new webhook functionality thoroughly, including edge cases.
- Verify that existing HTTP request features still work as expected.
- Update any relevant documentation to reflect these changes.
- Consider adding unit tests for the new webhook logic if not already done.
Line range hint
313-317: LGTM: HTTP request handling refactored.The replacement of the
WEBHOOKcase withHTTP_REQUESTin theBlockSettingscomponent is consistent with the new imports and suggests a refactoring of HTTP request handling. This change aligns with best practices by separating HTTP requests from webhook functionality.To ensure this change doesn't negatively impact existing functionality, please verify:
- All existing HTTP request features still work as expected.
- Any previous webhook functionality that relied on this case has been properly migrated or accounted for in the new webhook implementation.
✅ Verification successful
All references to
IntegrationBlockType.WEBHOOKhave been successfully removed.The search confirmed that there are no remaining references to the old
WEBHOOKintegration type in the TypeScript files. This ensures that the refactoring toHTTP_REQUESTis complete and should not negatively impact existing functionality.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for any remaining references to the old WEBHOOK integration type rg "IntegrationBlockType.WEBHOOK" --type typescriptLength of output: 179
Script:
#!/bin/bash # Search for any remaining references to the old WEBHOOK integration type in TypeScript files rg "IntegrationBlockType.WEBHOOK" --glob "*.ts" --glob "*.tsx"Length of output: 62
347-354: LGTM: Webhook functionality added as a logic block.The addition of the
LogicBlockType.WEBHOOKcase in theBlockSettingscomponent successfully implements the new webhook functionality. This change aligns perfectly with the PR objective of adding a webhook block.To ensure the completeness of this implementation, please verify:
- The
WebhookSettingscomponent is properly implemented and handles all necessary webhook configurations.- The
blockIdprop is used correctly within theWebhookSettingscomponent.- The
optionsandonOptionsChangeprops are properly utilized to manage webhook settings.✅ Verification successful
Verified: WebhookSettings component correctly implements required props.
The
WebhookSettingscomponent properly handles theblockId,options, andonOptionsChangeprops as intended. Each prop is utilized effectively to manage webhook configurations, ensuring the component functions as expected within theBlockSettingscomponent.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check the implementation of the WebhookSettings component rg -A 20 "export const WebhookSettings" --type typescriptLength of output: 179
Script:
#!/bin/bash # Check the implementation of the WebhookSettings component using file glob patterns rg -A 20 "export const WebhookSettings" --glob '*.ts*'Length of output: 2366
Script:
#!/bin/bash # Verify usage of blockId in WebhookSettings component rg "blockId" apps/builder/src/features/blocks/logic/webhook/components/WebhookSettings.tsx # Verify usage of options in WebhookSettings component rg "options" apps/builder/src/features/blocks/logic/webhook/components/WebhookSettings.tsx # Verify usage of onOptionsChange in WebhookSettings component rg "onOptionsChange" apps/builder/src/features/blocks/logic/webhook/components/WebhookSettings.tsxLength of output: 908
packages/embeds/js/src/components/ConversationContainer/ConversationContainer.tsx (1)
Line range hint
1-402: Overall, the changes look good and align with the PR objectives.The modifications to
processClientSideActionsand the addition ofconvertSubmitContentToMessageenhance the functionality of theConversationContainercomponent. These changes support the implementation of the webhook block feature and improve the handling of different input types.The code is well-structured, and the new additions maintain the existing code quality. The minor suggestions provided earlier will further improve code clarity and robustness.
packages/bot-engine/src/schemas/api.ts (8)
79-79: LGTM: New type exports enhance type safetyThe addition of
MessageandChatSessiontype exports, inferred from their respective schemas, is a good practice. It improves type safety and makes it easier to use these types consistently across the codebase.
Line range hint
159-173: LGTM: Comprehensive ChatMessage schema with type exportThe
chatMessageSchemais well-defined as a discriminated union of various message types, providing flexibility and type safety. The addition of theChatMessagetype export is a good practice for consistent usage across the codebase.
Line range hint
175-194: LGTM: Well-structured StartTypebot schemas with version handlingThe addition of
StartTypebotV5andStartTypebotV6type exports, along with thestartTypebotSchemausing a preprocessor and discriminated union, is a good approach. It allows for proper version handling and backward compatibility, which is crucial for maintaining API stability.
Line range hint
226-262: LGTM: Comprehensive StartChatInput schema with clear documentationThe
StartChatInputschema and type export are well-defined. The schema includes detailed descriptions for each field, appropriate default values, and type-safe enums. This level of detail in the schema definition enhances usability and reduces the likelihood of errors.
Line range hint
280-317: LGTM: Well-defined StartPreviewChatInput schema with appropriate extensionsThe
StartPreviewChatInputschema and type export are well-structured. The schema extends the concept ofStartChatInputwith additional fields specific to preview functionality. The use of optional fields, default values, and detailed descriptions enhances its usability and flexibility.
Line range hint
319-320: LGTM: Reusable RuntimeOptions schemaThe
RuntimeOptionsschema and type export are appropriately defined. Basing it on the existingpaymentInputRuntimeOptionsSchemapromotes consistency, while making it optional provides flexibility in its usage across different contexts.
Line range hint
399-411: LGTM: Comprehensive chat response schemas with shared baseThe
StartChatResponseandContinueChatResponseschemas and type exports are well-structured. The use of a commonchatResponseBaseSchemapromotes consistency between start and continue responses. These schemas provide comprehensive information about the chat session, including client-side actions and logs, which enhances the flexibility and functionality of the API.
Line range hint
1-411: Overall: Excellent schema definitions and type exportsThe changes in this file significantly enhance the API's type safety, consistency, and usability. The addition of new type exports, well-structured schemas, and comprehensive documentation for each schema demonstrates a thoughtful approach to API design. The use of Zod for schema definition provides strong type safety and runtime validation, which will help prevent errors and improve the developer experience when working with this API.
Some notable strengths of these changes include:
- Consistent use of discriminated unions for handling different message types and versions.
- Detailed documentation for each schema field, improving API usability.
- Appropriate use of optional fields and default values to provide flexibility.
- Reuse of common schemas to maintain consistency across related structures.
These improvements will make the API more robust and easier to work with for both internal development and external consumers.
packages/env/src/index.ts (2)
446-453: LGTM: NewpartykitEnvconfiguration looks good.The new
partykitEnvconfiguration is well-structured and consistent with other environment configurations in the file. It correctly defines theNEXT_PUBLIC_PARTYKIT_HOSTvariable for both client and runtime environments.
489-489: LGTM: Proper integration ofpartykitEnvinto theenvexport.The
partykitEnvconfiguration is correctly integrated into theenvexport. It's added to both theclientandexperimental__runtimeEnvsections, following the established pattern in the file.Also applies to: 504-504
packages/blocks/core/src/migrations/migrateWebhookBlock.ts (4)
3-5: Imports updated appropriately.The imports have been correctly updated to reference HTTP request constants and schemas, aligning with the migration from webhook blocks to HTTP request blocks.
7-7: Import ofisHttpRequestBlockis correct.Importing
isHttpRequestBlockensures that the block type is properly identified during migration.
34-36: Usage ofdefaultHttpRequestAttributesis appropriate.Utilizing
defaultHttpRequestAttributesensures that default values for HTTP requests are applied when a webhook is not found, which maintains consistency in the block's attributes.
13-13: 🛠️ Refactor suggestionConsider renaming the function to reflect its new purpose and verify usage across the codebase.
The function
migrateWebhookBlocknow handles HTTP request blocks by checkingisHttpRequestBlock(block). To improve clarity and maintainability, consider renaming the function tomigrateHttpRequestBlock. Additionally, ensure all references to this function are updated accordingly throughout the codebase.You can run the following script to find all references to
migrateWebhookBlock:✅ Verification successful
Let's perform a more thorough search to ensure all references to
migrateWebhookBlockare identified.[/run_scripts]
All references to
migrateWebhookBlockhave been verified.
packages/typebot/src/migrations/migrateTypebotFromV3ToV4.ts
- Import of
migrateWebhookBlock- Usage in
group.blocks.map(migrateWebhookBlock(webhooks))packages/blocks/core/src/migrations/migrateWebhookBlock.ts
- Export of
migrateWebhookBlock🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Find all references to `migrateWebhookBlock` in the codebase. rg 'migrateWebhookBlock'Length of output: 395
Script:
#!/bin/bash # Description: Perform a case-insensitive search for all references to `migrateWebhookBlock` in the codebase. rg -i 'migrateWebhookBlock'Length of output: 398
apps/viewer/src/pages/api/v1/typebots/[typebotId]/blocks/[blockId]/whatsapp/[phone]/executeTestWebhook.ts (1)
45-47:⚠️ Potential issueHandle potential JSON parsing errors and simplify request body handling
If
req.bodyis a string containing invalid JSON,JSON.parse(req.body)will throw an error, potentially causing a server crash. To prevent this, add error handling for JSON parsing. Additionally, sincereq.bodyis typically parsed automatically in Next.js forapplication/jsoncontent types, you can simplify the code.Apply this diff to handle parsing errors and simplify the logic:
+ let requestData; + try { + requestData = typeof req.body === "string" ? JSON.parse(req.body) : req.body; + } catch (error) { + return badRequest(res, "Invalid JSON in request body"); + } - data: - typeof req.body === "string" - ? JSON.stringify({ data: JSON.parse(req.body) }) - : JSON.stringify({ data: req.body }, null, 2), + data: JSON.stringify({ data: requestData }, null, 2),Alternatively, if you are certain that
req.bodyis always an object:- data: - typeof req.body === "string" - ? JSON.stringify({ data: JSON.parse(req.body) }) - : JSON.stringify({ data: req.body }, null, 2), + data: JSON.stringify({ data: req.body }, null, 2),Ensure that the request body is being correctly parsed by Next.js middleware and adjust the code accordingly.
packages/bot-engine/src/blocks/integrations/httpRequest/saveDataInResponseVariableMapping.ts (3)
12-17: Separation of concerns in thePropstypeThe
Propstype has been updated to replace theblockproperty with more granular properties:blockId,responseVariableMapping, andoutgoingEdgeId. This enhances clarity and reduces dependency on the entire block object, making the function more modular and easier to maintain.
83-83: Use consistent naming forcurrentBlockIdparameterThe parameter
currentBlockIdis now correctly assigned usingblockId, aligning with the updatedPropstype. This change improves code consistency and reduces potential confusion.
86-94: EnsureoutgoingEdgeIdis correctly propagated in the responseBy updating the references to
outgoingEdgeId, the function now correctly passes this value in the returnedExecuteIntegrationResponse. This ensures that the flow continues as expected after the integration executes.apps/builder/src/features/blocks/integrations/httpRequest/api/subscribeHttpRequest.ts (4)
4-4: Update import to reflect module changesThe import statement at line 4 correctly updates to import
isHttpRequestBlockfrom the new module path, aligning with the shift from webhook to HTTP request blocks.
12-19: Update API metadata to reflect HTTP requestThe metadata in the API has been updated to replace references to "webhook" with "HTTP request", which is appropriate given the context change.
- Method name updated to
subscribeHttpRequest.- OpenAPI
path,summary, andtagsupdated accordingly.
61-74: Verify that block options are updated correctlyBetween lines 61-74, the code updates the
webhookoptions within thehttpRequestBlock. Ensure that the merging of options doesn't inadvertently overwrite existing configurations.Review the merging logic to confirm that:
- Existing options are preserved.
- Only the
webhook.urlis updated with the newurlvalue.
6-6: Verify the import path forHttpRequestBlockAt line 6, the import path for
HttpRequestBlockhas been updated. Ensure that the module@typebot.io/blocks-integrations/httpRequest/schemaexportsHttpRequestBlockcorrectly.You can run the following script to confirm:
apps/viewer/src/pages/api/v1/typebots/[typebotId]/blocks/[blockId]/results/[resultId]/executeWebhook.ts (1)
19-98: Overall implementation meets the functional requirementsThe handler effectively processes the webhook execution, handling both WhatsApp and non-WhatsApp chat sessions appropriately. The flow of logic is clear, and the usage of imported utilities aligns with best practices.
apps/builder/src/pages/api/typebots/[typebotId]/blocks/[blockId]/testHttpRequest.ts (1)
41-41:⚠️ Potential issueUpdate error message to reflect HTTP request block
The error message currently says "Webhook block not found", which may be confusing since the code now handles HTTP request blocks. It should be updated to accurately reflect the block type.
Apply this diff to update the error message:
- return notFound(res, "Webhook block not found"); + return notFound(res, "HTTP request block not found");Likely invalid or redundant comment.
packages/embeds/js/src/queries/startChatQuery.ts (2)
52-56: Modularization Enhances Code ReadabilityThe extraction of
resumeChatAfterPaymentRedirectinto a separate function improves the modularity and readability of the code. The function call withinstartChatQuerycorrectly passes the required parameters.
60-67: Refactored Preview Chat Initialization is CorrectThe introduction of
startPreviewChatstreamlines the code for starting a preview chat. The parameters are correctly passed, and the function enhances maintainability.apps/viewer/src/pages/api/typebots/[typebotId]/blocks/[blockId]/executeWebhook.ts (1)
2-9: Imports updated correctly for HTTP request functionalityThe import statements have been appropriately updated to reflect the transition from webhook to HTTP request functionality.
packages/whatsapp/src/sendChatReplyToWhatsApp.ts (5)
35-35: Function Signature Updated SuccessfullyThe function
sendChatReplyToWhatsAppnow returnsPromise<{ shouldWaitForWebhook: boolean }>to accommodate the new control flow for webhook handling. This change ensures that the callers can handle the new return value appropriately.
107-107: Consistent Passing of Typing Emulation SettingsThe
getTypingDurationfunction now receivestypingEmulationdirectly fromstate.typingEmulation, ensuring consistency in how typing durations are calculated throughout the session.
123-126: Correct Handling of 'listenForWebhook' ActionThe code properly checks for
action.type === "listenForWebhook"and returns{ shouldWaitForWebhook: true }. This allows the system to wait for a webhook response as needed, aligning with the new feature requirements.
179-179: Passing Typing Emulation Settings for Input MessagesWhen sending input messages,
typingEmulationis now sourced fromstate.typingEmulation, maintaining consistent use of session-specific settings.
203-203: Default Return Value Ensures Proper FlowThe return statement
return { shouldWaitForWebhook: false };at the end of the function ensures that, unless a webhook wait is required, the function will signal that it does not need to wait. This maintains the correct control flow.apps/builder/src/features/blocks/integrations/httpRequest/components/HttpRequestAdvancedConfigForm.tsx (1)
96-96:⚠️ Potential issueRedundant condition and outdated reference to
webhookIn the
executeTestRequestfunction, theifstatement conditionally callsawait save();in both theifandelsebranches, making the condition redundant. Additionally, the condition checksoptions?.webhook, but sincewebhookhas been replaced withhttpRequest, this condition may be outdated. Consider removing the condition or updating it appropriately.Suggested fix:
- if (!options?.webhook) await save(); - else await save(); + await save();Likely invalid or redundant comment.
packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts (2)
85-86: Verify that client-side action types are consistentLines 85-86 specify a client-side action with
type: "httpRequestToExecute". Please verify that this action type is correctly handled on the client side and that there are no legacy references to"webhookToExecute".
85-86: EnsureexpectsDedicatedReplyis correctly handledIn the client-side action returned on lines 85-86,
expectsDedicatedReplyis set totrue. Verify that the client correctly handles this flag and that it doesn't interfere with the user experience, especially in scenarios where an immediate response is not necessary.packages/whatsapp/src/resumeWhatsAppFlow.ts (4)
30-31: Optional Parameters in Props Enhance FlexibilityThe addition of optional
contactandforceparameters in thePropstype improves the flexibility of theresumeWhatsAppFlowfunction, allowing it to handle cases where these values may not be provided.
64-68: Proper Validation of phoneNumberId Ensures SecurityThe new condition checks if the
phoneNumberIdfrom the incoming message matches the one in the credentials. This validation prevents processing messages intended for a different phone number, enhancing the security of the application.
184-187: Verify Logic for Updating currentBlockIdThe logic setting
currentBlockIdtoundefinedwhen!input && !shouldWaitForWebhookis true may affect the bot flow control. Ensure that this condition aligns with the intended behavior and does not cause unexpected navigation issues.
98-98: Check Potential Concurrency Issues with isReplying FlagThe condition
if (session?.isReplying && !force)now includes theforceparameter to override the check. Ensure that this change does not introduce race conditions or unintended behavior, especially in concurrent scenarios.You can verify the usage of the
isReplyingflag across the codebase with the following script:packages/bot-engine/src/continueBotFlow.ts (2)
39-39: Import statement for 'saveDataInResponseVariableMapping' is correct.The import statement aligns with the usage in the code and appears to be properly structured.
244-246:⚠️ Potential issueVerify the correct block type for 'WEBHOOK' in the conditional check.
It appears that
block.type === LogicBlockType.WEBHOOKis used, butWEBHOOKmight be incorrectly categorized underLogicBlockType. Please verify ifWEBHOOKshould be underIntegrationBlockTypeinstead.Run the following script to verify the definition of
WEBHOOKblock type:This script will help determine if
WEBHOOKis correctly categorized.✅ Verification successful
Verified: 'WEBHOOK' is correctly categorized under
LogicBlockType.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check whether 'WEBHOOK' is part of 'LogicBlockType' or 'IntegrationBlockType'. # Search for 'WEBHOOK' in 'LogicBlockType' definitions rg --type ts 'export enum LogicBlockType' -A 10 | rg 'WEBHOOK' # Search for 'WEBHOOK' in 'IntegrationBlockType' definitions rg --type ts 'export enum IntegrationBlockType' -A 10 | rg 'WEBHOOK'Length of output: 193
packages/embeds/js/src/features/blocks/logic/webhook/listenForWebhook.ts
Outdated
Show resolved
Hide resolved
apps/builder/src/features/blocks/integrations/httpRequest/api/getResultExample.ts
Show resolved
Hide resolved
packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts
Outdated
Show resolved
Hide resolved
packages/bot-engine/src/blocks/integrations/httpRequest/executeHttpRequestBlock.ts
Show resolved
Hide resolved
baptisteArno
force-pushed
the
feat/webhook-block
branch
from
4ee9428 to
4511d2a
Compare
Suspect IssuesThis pull request was deployed and Sentry observed the following issues:
Did you find this useful? React with a 👍 or 👎 |
Closes #1531