Skip to content

Conversation

@jcortes
Copy link
Collaborator

@jcortes jcortes commented Oct 28, 2025

WHY

Resolves #18861

Summary by CodeRabbit

  • Chores

    • Updated version numbers for Lusha actions and main package (multiple action bumps; package 0.2.0 → 0.2.1).
  • Improvements

    • Enhanced pagination for more reliable API result handling.
    • Search/filter behavior: location handling updated to consistently support multiple locations (format adjusted) across contact and company search/enrich flows.

@jcortes jcortes self-assigned this Oct 28, 2025
@vercel
Copy link

vercel bot commented Oct 28, 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 Nov 4, 2025 8:53pm
pipedream-docs-redirect-do-not-edit Ignored Ignored Nov 4, 2025 8:53pm

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Oct 28, 2025

Walkthrough

This pull request updates version metadata across multiple Lusha action modules, adjusts several actions to map single location inputs to locations, and refactors paginate in lusha.app.mjs to accept data (instead of params) and iterate over response.data results.

Changes

Cohort / File(s) Summary
Action version bumps (individual)
components/lusha/actions/company-enrich/company-enrich.mjs, components/lusha/actions/contact-enrich/contact-enrich.mjs
Updated exported version strings: company-enrich 0.0.4 → 0.0.5; contact-enrich 0.0.3 → 0.0.4. No functional changes.
Action version bumps + minor logic
components/lusha/actions/company-search/company-search.mjs
Version bumped 0.0.3 → 0.0.4; run() now maps locations as parseObject(this.locations).map(country => ({ country })) and uses explicit if-block braces for include fields.
Action version bumps + location field rename
components/lusha/actions/contact-search/contact-search.mjs, components/lusha/actions/search-and-enrich-contacts/search-and-enrich-contacts.mjs
Versions bumped (contact-search 0.0.3 → 0.0.4; search-and-enrich-contacts 0.0.2 → 0.0.3). Mapping changed from include.locationinclude.locations when building payload.
Composite action version bump
components/lusha/actions/search-and-enrich-companies/search-and-enrich-companies.mjs
Version bumped 0.0.2 → 0.0.3. No other changes.
App refactor: pagination
components/lusha/lusha.app.mjs
paginate signature changed from paramsdata; payload uses data.pages; requests now consume response.data and iterate over results = response.data; loop termination uses results.length.
Package metadata
components/lusha/package.json
Package version bumped 0.2.0 → 0.2.1.

Sequence Diagram(s)

sequenceDiagram
    participant Caller
    participant Paginate as paginate()
    participant API as Lusha API

    Note over Caller,Paginate: Old paginate signature
    Caller->>Paginate: paginate({ fn, params={}, maxResults })
    Paginate->>Paginate: payload.pages = params.pages
    Paginate->>API: _makeRequest(payload)
    API-->>Paginate: response
    Paginate->>Paginate: iterate over response (data assumed in payload)
    Paginate-->>Caller: accumulated results

    Note over Caller,Paginate: New paginate signature
    Caller->>Paginate: paginate({ fn, data={}, maxResults })
    Paginate->>Paginate: payload.pages = data.pages
    Paginate->>API: _makeRequest(payload)
    API-->>Paginate: response
    Paginate->>Paginate: results = response.data → iterate over results
    Paginate-->>Caller: accumulated results
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

  • Attention needed:
    • Verify callers of paginate() are updated to pass data instead of params.
    • Review company-search location mapping change (mapping each location to { country }) for API compatibility.
    • Confirm include.locationinclude.locations changes in contact-related actions align with API contract and tests.
    • Ensure package version bump is consistent with release process.

Poem

🐰 I hopped through lines of versioned cheer,
I wrapped each location in a tiny gear,
paginate learned to read response.data bright,
small bumps and mappings — a tidy flight,
carrots and CI — everything's near! 🥕

Pre-merge checks and finishing touches

❌ Failed checks (1 warning, 1 inconclusive)
Check name Status Explanation Resolution
Linked Issues check ⚠️ Warning The PR addresses version bumps and parameter mapping changes but does not implement critical requirements: fixing the API key inclusion in request headers, adding domain search to company actions, or adding email/LinkedIn URL parameters to contact actions. Ensure the PR includes fixes for API key header inclusion [#18861], domain-based company search [#18861], and email/LinkedIn URL contact search parameters [#18861] before merging.
Description check ❓ Inconclusive The description only references the linked issue without providing substantive detail about the changes made or how the authentication issue is being resolved. Expand the description to explain what changes were made to fix the authentication issue, including details about the API key handling and any parameter updates.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title '[FIX] Lusha API Authentication Issue' accurately summarizes the main change: fixing an authentication problem in the Lusha app by updating API configurations across multiple action components.
Out of Scope Changes check ✅ Passed All changes are focused on updating version numbers, refactoring location parameter handling, and modernizing the paginate function signature—all directly related to supporting the Lusha API fixes outlined in issue #18861.
✨ 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 fix-lusha-auth-issues

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b0364a7 and 2d2a242.

📒 Files selected for processing (8)
  • components/lusha/actions/company-enrich/company-enrich.mjs (1 hunks)
  • components/lusha/actions/company-search/company-search.mjs (2 hunks)
  • components/lusha/actions/contact-enrich/contact-enrich.mjs (1 hunks)
  • components/lusha/actions/contact-search/contact-search.mjs (2 hunks)
  • components/lusha/actions/search-and-enrich-companies/search-and-enrich-companies.mjs (1 hunks)
  • components/lusha/actions/search-and-enrich-contacts/search-and-enrich-contacts.mjs (2 hunks)
  • components/lusha/lusha.app.mjs (2 hunks)
  • components/lusha/package.json (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (5)
  • components/lusha/actions/company-enrich/company-enrich.mjs
  • components/lusha/package.json
  • components/lusha/actions/search-and-enrich-companies/search-and-enrich-companies.mjs
  • components/lusha/actions/company-search/company-search.mjs
  • components/lusha/actions/search-and-enrich-contacts/search-and-enrich-contacts.mjs
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2024-09-25T16:13:11.505Z
Learnt from: LucBerge
Repo: PipedreamHQ/pipedream PR: 14080
File: components/nocodb/nocodb.app.mjs:133-133
Timestamp: 2024-09-25T16:13:11.505Z
Learning: When implementing pagination with an offset, incrementing `args.params.offset` within the loop ensures correct tracking of the offset, particularly when a maximum count limit (`max`) is used.

Applied to files:

  • components/lusha/lusha.app.mjs
🧬 Code graph analysis (2)
components/lusha/actions/contact-search/contact-search.mjs (3)
components/lusha/actions/company-search/company-search.mjs (1)
  • include (68-68)
components/lusha/actions/search-and-enrich-companies/search-and-enrich-companies.mjs (1)
  • include (67-67)
components/lusha/actions/search-and-enrich-contacts/search-and-enrich-contacts.mjs (1)
  • include (75-75)
components/lusha/lusha.app.mjs (4)
components/lusha/actions/company-enrich/company-enrich.mjs (1)
  • response (32-38)
components/lusha/actions/company-search/company-search.mjs (1)
  • response (95-106)
components/lusha/actions/contact-enrich/contact-enrich.mjs (1)
  • response (32-38)
components/lusha/actions/contact-search/contact-search.mjs (1)
  • response (87-98)
⏰ 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). (4)
  • GitHub Check: pnpm publish
  • GitHub Check: Verify TypeScript components
  • GitHub Check: Publish TypeScript components
  • GitHub Check: Lint Code Base
🔇 Additional comments (5)
components/lusha/actions/contact-search/contact-search.mjs (2)

8-8: Version bump is appropriate for the API field mapping change.

The version increment correctly reflects the breaking change from location to locations in the request payload.


85-85: Correct field mapping to locations.

The change from include.location to include.locations aligns with the Lusha API's expected request body structure for the prospecting contact search endpoint, which expects an array of location objects.

components/lusha/actions/contact-enrich/contact-enrich.mjs (1)

7-7: Version bump aligns with PR-wide updates.

The version increment is consistent with other actions updated in this PR.

components/lusha/lusha.app.mjs (2)

144-163: Enhanced location property documentation improves usability.

The expanded description with field details and JSON example will help users construct valid location filter objects.


282-310: Verify parameter implementation scope against PR objectives

The review comment references PR objectives about adding email, LinkedIn URL, and domain parameters, but the code snippet shown (the paginate function at lines 282-310) is a utility helper for API iteration and doesn't relate to implementing search parameters.

The codebase shows:

  • Domain parameter: Already exists in components/lusha/lusha.app.mjs and is used in company-search
  • Email parameter: Genuinely missing from contact-search props
  • LinkedIn URL parameter: Genuinely missing from contact-search props

Before proceeding, clarify:

  1. Was the domain parameter added in this PR or is it pre-existing?
  2. Per issue [BUG] Lusha App - API Authentication Issue #18861, were email and LinkedIn parameters required for this PR or should they be tracked separately?
  3. Does the PR scope include modifying property definitions, or only the paginate utility?

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.

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: 1

Caution

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

⚠️ Outside diff range comments (2)
components/lusha/actions/search-and-enrich-contacts/search-and-enrich-contacts.mjs (1)

90-108: Critical: Pagination broken due to params vs data mismatch.

The manual pagination loop passes pagination info via params.pages (lines 95-100), but based on the refactored paginate method in lusha.app.mjs (line 272), pagination should now be in data.pages. The Lusha API likely expects pagination in the request body, not query parameters.

Apply this diff to fix the pagination:

     do {
       const {
         requestId, data = [],
       } = await this.lusha.searchContacts({
         $,
-        params: {
-          pages: {
-            page,
-            size: 50,
-          },
-        },
         data: {
+          pages: {
+            page,
+            size: 50,
+          },
           filters: {
             contacts: {
               include,
             },
           },
         },
       });
components/lusha/actions/search-and-enrich-companies/search-and-enrich-companies.mjs (1)

80-98: Critical: Pagination broken due to params vs data mismatch.

The manual pagination loop passes pagination info via params.pages (lines 85-90), but the refactored paginate method in lusha.app.mjs (line 272) now uses data.pages. This inconsistency will cause pagination to fail.

Apply this diff to fix the pagination:

     do {
       const {
         requestId, data = [],
       } = await this.lusha.searchCompanies({
         $,
-        params: {
-          pages: {
-            page,
-            size: 50,
-          },
-        },
         data: {
+          pages: {
+            page,
+            size: 50,
+          },
           filters: {
             companies: {
               include,
             },
           },
         },
       });
📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 36a8917 and b0364a7.

📒 Files selected for processing (8)
  • components/lusha/actions/company-enrich/company-enrich.mjs (1 hunks)
  • components/lusha/actions/company-search/company-search.mjs (1 hunks)
  • components/lusha/actions/contact-enrich/contact-enrich.mjs (1 hunks)
  • components/lusha/actions/contact-search/contact-search.mjs (1 hunks)
  • components/lusha/actions/search-and-enrich-companies/search-and-enrich-companies.mjs (1 hunks)
  • components/lusha/actions/search-and-enrich-contacts/search-and-enrich-contacts.mjs (1 hunks)
  • components/lusha/lusha.app.mjs (2 hunks)
  • components/lusha/package.json (1 hunks)
🧰 Additional context used
🧬 Code graph analysis (1)
components/lusha/lusha.app.mjs (4)
components/lusha/actions/company-enrich/company-enrich.mjs (1)
  • response (32-38)
components/lusha/actions/company-search/company-search.mjs (1)
  • response (78-89)
components/lusha/actions/contact-enrich/contact-enrich.mjs (1)
  • response (32-38)
components/lusha/actions/contact-search/contact-search.mjs (1)
  • response (87-98)
⏰ 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). (4)
  • GitHub Check: Publish TypeScript components
  • GitHub Check: pnpm publish
  • GitHub Check: Verify TypeScript components
  • GitHub Check: Lint Code Base
🔇 Additional comments (1)
components/lusha/lusha.app.mjs (1)

182-182: Verify whether hardcoded debug mode is acceptable for production use and whether API key exposure is a known/acceptable trade-off.

The Pipedream platform's debug feature intentionally exports the full request configuration (including the Authorization header with the API key) to step.debug_config when enabled. The cloneSafe() function performs only a deep clone without filtering sensitive data.

This hardcoding is atypical compared to how most components use the debug flag (primarily in source/webhook handlers). Since the original concern about API key exposure is technically valid, confirm whether this debug mode is:

  • Required for troubleshooting in production
  • An oversight that should be removed or made configurable
  • An accepted security/observability trade-off for this integration

If debug is not essential for production use, consider removing it or gating it behind an environment variable or component setting.

luancazarine
luancazarine previously approved these changes Nov 3, 2025
Copy link
Collaborator

@luancazarine luancazarine left a comment

Choose a reason for hiding this comment

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

Hi @jcortes, LGTM! Ready for QA!

@vunguyenhung
Copy link
Collaborator

@vunguyenhung
Copy link
Collaborator

Hello everyone, I have tested this PR and there're some test cases failed or needed improvement.

Please check test reports below for more information:

@jcortes
Copy link
Collaborator Author

jcortes commented Nov 4, 2025

HI @vunguyenhung about:

lusha - Company Search - Failed

Company search by name (Regression) - Failed

Improvements needed

Return value should include the requestId and other metadata, for the user to use on other actions.

Answer

This is not a good idea because we are using pagination so we end up with a requestId per pagination

lusha - Contact Search - Failed

Improvement needed - Improve Contact Locations prop

  • Contact Locations should be enhanced to be more user-friendly such as drop-down, etc.

Answer

I tried to use this endpoint but it doesn't work well with async options because it hits the daily rate limit for request too fast since the only way to use the endpoint is by looking for text as a parameter, so I've ended up improving the description for better UX

Please test again with latest push, thanks!

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.

[BUG] Lusha App - API Authentication Issue

4 participants