Skip to content

Conversation

michelle0927
Copy link
Collaborator

@michelle0927 michelle0927 commented Oct 17, 2025

Resolves #18764

Summary by CodeRabbit

  • New Features

    • Added new page-building capability with streamlined data source integration.
  • Chores

    • Bumped versions across multiple Notion action components (0.0.6→0.0.7, 1.0.3→1.0.4, etc.).
    • Added new dependency to support enhanced functionality.

Copy link

vercel bot commented Oct 17, 2025

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments
Project Deployment Preview Comments Updated (UTC)
pipedream-docs Ignored Ignored Oct 17, 2025 8:57pm
pipedream-docs-redirect-do-not-edit Ignored Ignored Oct 17, 2025 8:57pm

💡 Enable Vercel Agent with $100 free credit for automated AI reviews

Copy link
Contributor

coderabbitai bot commented Oct 17, 2025

Walkthrough

This PR integrates the notion-helper package into Pipedream's Notion actions to leverage its batch API request splitting and block management capabilities. Core actions (append-block, create-page, create-page-from-database) are refactored to use createPage() and appendBlocks() functions, replacing internal chunking logic. Multiple version numbers are bumped accordingly, and the package dependency is added.

Changes

Cohort / File(s) Change Summary
Core notion-helper integration
components/notion/actions/append-block/append-block.mjs
Replaced manual batch chunking loop with single call to appendBlocks() from notion-helper; removed internal chunkArray helper and methods block; updated version from 0.3.11 to 0.4.0; now returns response.apiResponses instead of flattened results.
New page builder method
components/notion/actions/common/base-page-builder.mjs
Added buildPageFromDataSource() method that converts Markdown to Notion blocks, instantiates a page builder with optional metadata (icon, cover), applies properties, and invokes createPage() from notion-helper; added imports for createPage and createNotionBuilder.
Refactored page creation actions
components/notion/actions/create-page/create-page.mjs
Removed internal buildPage, splitChildrenArray, and appendChildren helper methods; replaced manual page construction and chunked child appends with single buildPageFromDataSource() call; version bumped from 0.2.24 to 0.3.0.
Updated database page creation
components/notion/actions/create-page-from-database/create-page-from-database.mjs
Refactored buildPage() to return propertiesArray instead of combined object; replaced manual page creation flow with buildPageFromDataSource() call; removed MAX_BLOCKS pagination logic; version remains unchanged.
Dependency management
components/notion/package.json
Added notion-helper dependency (^1.3.27); package version bumped from 1.0.4 to 1.0.5.
Patch version bumps
components/notion/actions/complete-file-upload/complete-file-upload.mjs, create-file-upload/create-file-upload.mjs, delete-block/delete-block.mjs, list-file-uploads/list-file-uploads.mjs, retrieve-file-upload/retrieve-file-upload.mjs, send-file-upload/send-file-upload.mjs, update-block/update-block.mjs
Version bumped 0.0.6 → 0.0.7 (no functional changes).
Minor version bumps
components/notion/actions/create-database/create-database.mjs, duplicate-page/duplicate-page.mjs, update-database/update-database.mjs, update-page/update-page.mjs
Version bumped (create-database: 0.1.3 → 0.1.4; duplicate-page: 0.0.21 → 0.0.22; update-database: 1.0.3 → 1.0.4; update-page: 2.0.3 → 2.0.4); no functional changes.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant AppendBlock as append-block action
    participant Helper as notion-helper
    participant NotionAPI as Notion API

    User->>AppendBlock: append blocks to page
    AppendBlock->>AppendBlock: prepare block data
    AppendBlock->>Helper: appendBlocks(client, block_id, children)
    
    Note over Helper: Internal batch splitting logic
    Helper->>Helper: split blocks respecting API limits<br/>(nesting depth, array size, total blocks, character limits)
    
    loop For each batch request
        Helper->>NotionAPI: append_block_children API call
        NotionAPI-->>Helper: response
    end
    
    Helper-->>AppendBlock: return apiResponses array
    AppendBlock-->>User: success summary + responses
Loading
sequenceDiagram
    participant User
    participant CreatePage as create-page action
    participant PageBuilder as base-page-builder
    participant Helper as notion-helper
    participant NotionAPI as Notion API

    User->>CreatePage: create page (pageContent, metadata)
    CreatePage->>PageBuilder: buildPageFromDataSource({pageContent, parentPageId, properties, icon, cover})
    
    PageBuilder->>PageBuilder: convert Markdown to blocks
    PageBuilder->>Helper: createNotionBuilder()
    Helper-->>PageBuilder: page builder instance
    
    PageBuilder->>PageBuilder: apply properties to builder
    PageBuilder->>PageBuilder: set icon & cover
    PageBuilder->>Helper: createPage(client, pageBuilder)
    
    Note over Helper: Internal request splitting<br/>if needed
    Helper->>NotionAPI: create_page API call(s)
    NotionAPI-->>Helper: response(s)
    
    Helper-->>PageBuilder: API response
    PageBuilder-->>CreatePage: response
    CreatePage-->>User: created page
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

The changes mix homogeneous version bumps (low effort) with heterogeneous functional refactoring (higher effort). The core integration logic in append-block.mjs, base-page-builder.mjs, create-page.mjs, and create-page-from-database.mjs requires careful review to verify correct delegation to notion-helper functions and proper data flow. However, the patterns are consistent and the refactoring is largely substitutive (replacing internal logic with external library calls) rather than introducing entirely new behaviors.

Poem

🐰 Chunking and batching, oh what a quest!
The notion-helper package knows best,
No more manual loops that split and strain,
One call now handles the whole refrain,
API limits conquered with grace,
Blocks flow freely through cyberspace!

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Description Check ⚠️ Warning The pull request description is minimal and contains only "Resolves #18764" without providing any substantive explanation of the changes or fulfilling the "WHY" section specified in the repository's description template. While the linked issue provides context, the description itself does not explain the rationale, implementation approach, or scope of the changes directly to reviewers reading the PR. The PR description should be expanded to include the "WHY" section from the template, explaining that this PR integrates notion-helper to address Notion API request limit failures (particularly for nested blocks and large arrays). The description should also briefly describe how the integration works (e.g., adding notion-helper as a dependency and refactoring actions to use createPage() and appendBlocks()).
✅ Passed checks (4 passed)
Check name Status Explanation
Title Check ✅ Passed The title "Notion improvements - use notion-helper" is concise and clearly identifies the primary change in the pull request. It directly reflects the main objective of integrating the notion-helper package into Notion actions, and a developer scanning commit history would immediately understand what this PR accomplishes without ambiguity.
Linked Issues Check ✅ Passed The code changes directly implement the primary requirements from issue #18764: notion-helper is added as a dependency in package.json [#18764], the append-block action is refactored to use appendBlocks() [#18764], and a new buildPageFromDataSource method is introduced that integrates createPage() for page creation [#18764]. These changes provide the API request splitting capabilities described in the issue, including handling nested blocks, large block arrays, and Notion API limits through the notion-helper package's integrated request handling.
Out of Scope Changes Check ✅ Passed All changes in the pull request are directly related to integrating notion-helper into Notion actions as specified in issue #18764. The version bumps across multiple action files reflect the expected versioning for updated components. The refactoring of create-page.mjs, create-page-from-database.mjs, and append-block.mjs to use the new buildPageFromDataSource and appendBlocks methods are all in scope, as is the addition of the new buildPageFromDataSource method itself in base-page-builder.mjs.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch issue-18764

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@michelle0927 michelle0927 marked this pull request as ready for review October 17, 2025 20:58
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
components/notion/actions/complete-file-upload/complete-file-upload.mjs (1)

2-5: Based on my verification:

  1. base-page-builder content: I confirmed it exports only page/property/block building methods (buildPageFromDataSource, buildPageProperties, formatChildBlocks, etc.)—none related to file uploads.

  2. complete-file-upload purpose: This API finalizes a mode=multi_part file upload after all parts have been sent successfully—a simple file upload completion operation.

  3. Mismatch confirmed: The action spreads properties from a page-builder base into a file-upload-only action, creating semantic misalignment and unused inheritance.

Use the appropriate base for this action—likely a generic app-only base or no base at all if the action only requires the Notion app connection.

Verify that the complete-file-upload.mjs action:

  • Only accepts a file_upload_id prop
  • Calls the Notion API's completeFileUpload() endpoint
  • Does not need or use any page-building, property-handling, or block-formatting methods from base-page-builder

If confirmed, remove the base-page-builder import and spread, then add only the notion app import to the action's props.

🧹 Nitpick comments (3)
components/notion/actions/common/base-page-builder.mjs (3)

305-307: Consider validating mutually exclusive parent parameters.

The method accepts both parentDataSourceId and parentPageId. If both are provided, both will be set on the builder (lines 323-328). Verify that notion-helper handles this correctly, or add validation to ensure only one parent type is specified.

 async buildPageFromDataSource({
   pageContent, parentDataSourceId, parentPageId, properties = [], icon, cover,
 }) {
+  if (parentDataSourceId && parentPageId) {
+    throw new ConfigurationError("Cannot specify both parentDataSourceId and parentPageId");
+  }

330-333: Add error handling for invalid property types.

The dynamic method invocation on line 332 will throw if propertyTypeCamelCase doesn't correspond to a valid builder method. This could happen with unsupported or malformed property types.

 for (const property of properties) {
   const propertyTypeCamelCase = property.type.replace(/_([a-z])/g, (_, c) => c.toUpperCase());
-  pageBuilder = pageBuilder[propertyTypeCamelCase](property.label, property.value);
+  if (typeof pageBuilder[propertyTypeCamelCase] !== 'function') {
+    throw new ConfigurationError(`Unsupported property type: ${property.type}`);
+  }
+  try {
+    pageBuilder = pageBuilder[propertyTypeCamelCase](property.label, property.value);
+  } catch (error) {
+    throw new ConfigurationError(`Failed to set property "${property.label}" of type "${property.type}": ${error.message}`);
+  }
 }

309-315: Improve error message handling.

The error handler assumes error.message exists, but if markdownToBlocks throws a non-Error object, this could fail. Use optional chaining or ensure the error is properly formatted.

       try {
         pageBlocks = markdownToBlocks(pageContent);
       } catch (error) {
-        throw new ConfigurationError(`Failed to convert Markdown content to Notion blocks: ${error.message}`);
+        throw new ConfigurationError(`Failed to convert Markdown content to Notion blocks: ${error?.message || error}`);
       }
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between aa877f9 and ed576de.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (16)
  • components/notion/actions/append-block/append-block.mjs (2 hunks)
  • components/notion/actions/common/base-page-builder.mjs (2 hunks)
  • components/notion/actions/complete-file-upload/complete-file-upload.mjs (1 hunks)
  • components/notion/actions/create-database/create-database.mjs (1 hunks)
  • components/notion/actions/create-file-upload/create-file-upload.mjs (1 hunks)
  • components/notion/actions/create-page-from-database/create-page-from-database.mjs (2 hunks)
  • components/notion/actions/create-page/create-page.mjs (2 hunks)
  • components/notion/actions/delete-block/delete-block.mjs (1 hunks)
  • components/notion/actions/duplicate-page/duplicate-page.mjs (1 hunks)
  • components/notion/actions/list-file-uploads/list-file-uploads.mjs (1 hunks)
  • components/notion/actions/retrieve-file-upload/retrieve-file-upload.mjs (1 hunks)
  • components/notion/actions/send-file-upload/send-file-upload.mjs (1 hunks)
  • components/notion/actions/update-block/update-block.mjs (1 hunks)
  • components/notion/actions/update-database/update-database.mjs (1 hunks)
  • components/notion/actions/update-page/update-page.mjs (1 hunks)
  • components/notion/package.json (2 hunks)
🧰 Additional context used
🧬 Code graph analysis (4)
components/notion/actions/common/base-page-builder.mjs (2)
components/notion/actions/create-page-from-database/create-page-from-database.mjs (3)
  • properties (95-95)
  • properties (113-113)
  • response (114-120)
components/notion/actions/create-page/create-page.mjs (1)
  • response (52-64)
components/notion/actions/create-page/create-page.mjs (2)
components/notion/actions/common/base-page-builder.mjs (1)
  • response (353-356)
components/notion/actions/create-page-from-database/create-page-from-database.mjs (1)
  • response (114-120)
components/notion/actions/create-page-from-database/create-page-from-database.mjs (2)
components/notion/actions/update-page/update-page.mjs (2)
  • properties (94-94)
  • response (133-133)
components/notion/actions/create-page/create-page.mjs (1)
  • response (52-64)
components/notion/actions/append-block/append-block.mjs (1)
components/notion/actions/common/base-page-builder.mjs (1)
  • response (353-356)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
  • GitHub Check: Publish TypeScript components
  • GitHub Check: Verify TypeScript components
  • GitHub Check: Lint Code Base
🔇 Additional comments (16)
components/notion/actions/list-file-uploads/list-file-uploads.mjs (1)

1-32: Version bump is appropriate; no functional changes needed.

This file contains only a cosmetic version bump (0.0.6 → 0.0.7) and no functional changes. Since this is a read-only action (readOnlyHint: true), it does not integrate notion-helper's batch-splitting capabilities—which are intended for write operations like create-page and append-block. The change aligns with the overall PR scope of adding the dependency and bumping versions across Notion actions.

components/notion/actions/update-database/update-database.mjs (1)

10-10: Clarify the scope of this version bump.

This action updates a data source but is not listed in the PR objectives as a core action being refactored (only append-block, create-page, and create-page-from-database are mentioned). The version bump alone—without functional changes—is unclear in this context.

Should this file be modified in this PR? If so:

  • Does it need to integrate notion-helper for handling API limits?
  • If not, this version bump should be reverted or applied in a separate maintenance PR.

If this is a broad version bump across all Notion actions for consistency, that should be stated explicitly in the PR description.

components/notion/actions/update-block/update-block.mjs (1)

10-10: Version bump is appropriate as part of this PR's coordinated updates.

The version increment from 0.0.6 to 0.0.7 aligns with the PR's dependency updates and refactors to related Notion actions. Since update-block only updates individual blocks (not creating pages or appending blocks), it does not require notion-helper integration and the current implementation remains unchanged and correct.

components/notion/actions/retrieve-file-upload/retrieve-file-upload.mjs (1)

2-2: Verify the base module and confirm no functional changes.

This file imports and spreads a new base module from base-page-builder.mjs, which is not provided for review. The version is appropriately bumped to 0.0.7, but I cannot fully verify the impact of the base module integration.

The action's core logic (lines 26–31) remains unchanged, which is good; however, spreading the base module could introduce unexpected properties or methods that might conflict or alter behavior.

Please confirm:

  1. The base-page-builder.mjs module does not override or conflict with any properties defined in this action (e.g., key, name, props, run).
  2. The action's behavior is unchanged and passes all tests (especially the file-upload retrieval flow).

Also applies to: 5-5, 9-9

components/notion/actions/delete-block/delete-block.mjs (1)

9-9: LGTM: Version bump is appropriate.

The version increment aligns with the PR's broader update pattern. No notion-helper integration is required for this action since delete operations don't encounter the API request limits (deeply nested blocks, 100-block arrays, 1,000-block-per-request limits) that the PR addresses for create-page and append-blocks actions.

components/notion/actions/duplicate-page/duplicate-page.mjs (1)

10-10: Version bump approved as part of PR-wide synchronization.

The version is bumped from 0.0.21 to 0.0.22 as part of the PR-wide metadata update across Notion actions. This aligns with the integration of notion-helper into the Notion module infrastructure.

Since this action passes potentially large formattedChildren arrays to this.notion.createPage(page), please verify that the Notion app module's createPage method has been updated to use notion-helper's request splitting logic for handling nested blocks, character limits, and array size constraints.

components/notion/actions/complete-file-upload/complete-file-upload.mjs (1)

9-9: LGTM! Appropriate version bump.

The version increment aligns with the broader PR updates to Notion components and dependencies.

components/notion/actions/send-file-upload/send-file-upload.mjs (2)

11-11: Version bump is appropriate.

This patch-level version increment aligns with the release cycle for integrating notion-helper into Notion actions. This action correctly does not require notion-helper integration since it only handles file uploads, not page or block creation.


1-67: The review comment is based on incorrect assumptions and should be disregarded.

The latest published version of notion-helper is 1.3.25 (Sep 24, 2025), so the concern about 1.3.27 is technically valid. However, this codebase contains no references to notion-helper anywhere. The file under review (components/notion/actions/send-file-upload/send-file-upload.mjs) imports from @pipedream/platform and a local Notion app configuration—not from notion-helper. The review comment's concern about a notion-helper version mismatch does not apply to this PR.

Likely an incorrect or invalid review comment.

components/notion/actions/create-page-from-database/create-page-from-database.mjs (2)

97-108: Clarify property identification: name vs. ID.

The code uses property.name as the label (line 101) when building the properties array, but checks for properties[property.id] on line 99. This mixing of property name and ID could cause issues if Notion's API expects property IDs in certain contexts.

According to the related code in update-page.mjs (line 93), property labels are typically set to property.id. Consider using property.id consistently as the label unless property names are explicitly required by buildPageFromDataSource.

Based on learnings


111-123: Clean refactor to centralized page building.

The simplified flow delegates complex block batching and page construction to buildPageFromDataSource, which aligns with the PR objective to leverage notion-helper for API limit handling.

components/notion/actions/create-page/create-page.mjs (1)

51-67: Excellent simplification.

Removing the complex page-building logic and delegating to buildPageFromDataSource makes the code much more maintainable and aligns with the PR objective to use notion-helper for handling API limits.

components/notion/package.json (1)

17-17: No action required—notion-helper version 1.3.27 exists and is valid.

Verification confirms that version 1.3.27 is published on npm and is the latest available release. The dependency specification ^1.3.27 is correct and will not fail during installation.

components/notion/actions/append-block/append-block.mjs (2)

127-127: No issues found — method verified.

The _getNotionClient() method exists at components/notion/notion.app.mjs:219 and correctly returns new notion.Client({...}) with the proper authentication and Notion version configuration, confirming compatibility with @notionhq/client expectations.


126-133: Verify the return value structure for backward compatibility.

The return value changed to response.apiResponses. Without access to previous versions or tests showing the original return structure, carefully review any existing workflows consuming this action to ensure they expect the current output format. Consider checking git history to confirm what the previous return value structure was.

components/notion/actions/common/base-page-builder.mjs (1)

352-358: Verify the page builder output structure and createPage API contract.

The code assumes page.content and response.apiResponse properties exist based on builder and helper function contracts. Without definitive verification of these internal API guarantees, silent failures remain possible if the builder returns an unexpected structure or the helper function changes its response format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Notion actions improvement] Integrate notion-helper createPage() and appendBlocks() functions for splitting API requests

1 participant