-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New Components - ortto #14703
New Components - ortto #14703
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 3 Skipped Deployments
|
WalkthroughThis pull request introduces new modules and functionalities for the Ortto platform, including actions for creating custom activities, managing contacts, and opting out of SMS communications. It adds utility functions for object manipulation and a constant for limits, restructures the application setup, and updates the package metadata. The Changes
Assessment against linked issues
Possibly related PRs
Suggested reviewers
Poem
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 (
|
Sources - New Contact Created Actions - Create Custom Activity - Opt Out SMS
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 9
🧹 Outside diff range and nitpick comments (7)
components/ortto/common/utils.mjs (1)
18-41
: Add input validation to parseObjectThe function handles JSON parsing well but could benefit from input validation.
Consider this enhanced implementation:
export const parseObject = (obj) => { if (!obj) return undefined; + if (typeof obj !== 'string' && !Array.isArray(obj) && typeof obj !== 'object') { + return obj; + } if (Array.isArray(obj)) { return obj.map((item) => {components/ortto/actions/opt-out-sms/opt-out-sms.mjs (1)
36-37
: Enhance success message with more detailsThe success message could be more informative.
Consider this enhancement:
- $.export("$summary", `Successfully opted out SMS for User ID: ${this.userEmail}`); + $.export("$summary", `Successfully opted out SMS communications for user: ${this.userEmail}. Updated at: ${new Date().toISOString()}`);components/ortto/sources/new-contact-created/new-contact-created.mjs (2)
6-11
: Consider incrementing the version numberThe version is set to "0.0.1" which suggests this is the first implementation. However, given that this is implementing a core feature from issue #13209, consider starting with version "1.0.0" to indicate a stable, production-ready release.
43-45
: Enhance contact summary formattingThe current summary concatenation could result in multiple spaces when fields are empty. Consider using a more robust approach:
- return `New Contact: ${item.fields["str::first"] || ""} ${item.fields["str::last"] || ""} ${item.fields["str::email"] || ""} `; + const parts = [ + "New Contact:", + item.fields["str::first"], + item.fields["str::last"], + item.fields["str::email"], + ].filter(Boolean); + return parts.join(" ");components/ortto/actions/create-person/create-person.mjs (1)
4-9
: Consider starting with version 1.0.0Since this is a production-ready component that other developers will depend on, consider starting with version 1.0.0 instead of 0.0.1 to indicate stability and API readiness.
components/ortto/ortto.app.mjs (2)
12-29
: Optimize user email options loadingThe options method could be optimized to:
- Cache results to prevent unnecessary API calls
- Add error handling for API failures
async options({ page }) { + try { + if (!this._cachedContacts) { + this._cachedContacts = new Map(); + } + + const cacheKey = `page_${page}`; + if (this._cachedContacts.has(cacheKey)) { + return this._cachedContacts.get(cacheKey); + } + const { contacts } = await this.listPeople({ data: { limit: LIMIT, offset: LIMIT * page, fields: [ "str::first", "str::last", "str::email", ], }, }); - return contacts.map(({ fields }) => ({ + const options = contacts.map(({ fields }) => ({ label: `${fields["str::first"]} ${fields["str::last"]} (${fields["str::email"]})`, value: fields["str::email"], })); + + this._cachedContacts.set(cacheKey, options); + return options; + } catch (error) { + throw new Error(`Failed to load user emails: ${error.message}`); + } },
93-113
: Optimize pagination implementationThe current pagination implementation could be improved:
- Add handling for empty responses
- Add memory optimization for large datasets
async *paginate({ fn, data = {}, fieldName, ...opts }) { let hasMore = false; let page = 0; + let totalProcessed = 0; do { data.limit = LIMIT; data.offset = LIMIT * page++; + + try { const response = await fn({ data, ...opts, }); + + if (!response?.[fieldName]?.length) { + break; + } + for (const d of response[fieldName]) { yield d; + totalProcessed++; } hasMore = response.has_more; + + // Optional: Add a circuit breaker for safety + if (totalProcessed > 1000000) { + throw new Error('Pagination limit exceeded'); + } + } catch (error) { + throw new Error(`Pagination failed: ${error.message}`); + } } while (hasMore); },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
pnpm-lock.yaml
is excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (12)
components/ortto/.gitignore
(0 hunks)components/ortto/actions/create-custom-activity/create-custom-activity.mjs
(1 hunks)components/ortto/actions/create-person/create-person.mjs
(1 hunks)components/ortto/actions/opt-out-sms/opt-out-sms.mjs
(1 hunks)components/ortto/app/ortto.app.ts
(0 hunks)components/ortto/common/constants.mjs
(1 hunks)components/ortto/common/utils.mjs
(1 hunks)components/ortto/ortto.app.mjs
(1 hunks)components/ortto/package.json
(1 hunks)components/ortto/sources/common/base.mjs
(1 hunks)components/ortto/sources/new-contact-created/new-contact-created.mjs
(1 hunks)components/ortto/sources/new-contact-created/test-event.mjs
(1 hunks)
💤 Files with no reviewable changes (2)
- components/ortto/.gitignore
- components/ortto/app/ortto.app.ts
✅ Files skipped from review due to trivial changes (2)
- components/ortto/common/constants.mjs
- components/ortto/sources/new-contact-created/test-event.mjs
🧰 Additional context used
🪛 Biome (1.9.4)
components/ortto/common/utils.mjs
[error] 11-11: Avoid the use of spread (...
) syntax on accumulators.
Spread syntax should be avoided on accumulators (like those in .reduce
) because it causes a time complexity of O(n^2)
.
Consider methods such as .splice or .push instead.
(lint/performance/noAccumulatingSpread)
🔇 Additional comments (5)
components/ortto/package.json (1)
3-16
: Verify version bump rationale
The changes look good, but the version bump from 0.0.2 to 0.1.0 suggests significant changes. Please ensure this follows semantic versioning principles given the new Ortto components being added.
✅ Verification successful
Version bump to 0.1.0 is justified
The version bump from 0.0.2 to 0.1.0 is appropriate as this appears to be the initial implementation of the Ortto integration with multiple new components:
- 3 new actions: create-custom-activity, create-person, and opt-out-sms
- New source component: new-contact-created
- Common utilities and constants
- Base implementation for sources
This represents a significant feature addition that warrants a minor version bump according to semantic versioning principles.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if there are breaking changes that justify the minor version bump
git diff main -- components/ortto/ | grep -B 2 -A 2 "^[-+]" | grep -v "^[-+]package.json"
Length of output: 118
Script:
#!/bin/bash
# Let's first check what files exist in the components/ortto directory
fd . components/ortto/
# Then check the git history for this directory
git log --oneline -- components/ortto/
# Also check if there are any new files added in this PR
git status
Length of output: 1034
Script:
#!/bin/bash
# Let's check if these are new files by trying to find them in the current branch
git ls-tree -r HEAD:components/ortto --name-only
# Also let's check the content of the README to see if it provides any insights about the changes
cat components/ortto/README.md
Length of output: 1977
components/ortto/sources/new-contact-created/new-contact-created.mjs (1)
20-42
: Review and document field identifiers
The field identifiers use shorthand prefixes (str::, phn::, geo::, etc.) which might not be immediately clear to other developers. Consider:
- Adding documentation explaining these prefixes
- Verifying these match Ortto's API specifications
components/ortto/sources/common/base.mjs (1)
41-46
:
Fix potential race condition in lastDate update
The current implementation might miss events if multiple instances run simultaneously. Consider using timestamps instead of IDs for tracking:
if (responseArray.length) {
if (maxResults && (responseArray.length > maxResults)) {
responseArray.length = maxResults;
}
- this._setLastDate(responseArray[0].id);
+ this._setLastDate(Date.parse(responseArray[0].fields.c));
}
Likely invalid or redundant comment.
components/ortto/ortto.app.mjs (2)
79-85
: 🛠️ Refactor suggestion
Remove duplicate method definition in createPerson
The createPerson
method unnecessarily specifies method: "POST"
when it's already set in _makeRequest
:
createPerson(opts = {}) {
return this._makeRequest({
- method: "POST",
path: "/person/merge",
...opts,
});
},
Likely invalid or redundant comment.
48-56
: Verify API key security measures
Ensure proper handling of API credentials:
- Verify that the API key is properly encrypted in storage
- Consider implementing API key rotation mechanism
✅ Verification successful
API key handling follows secure practices
The implementation follows secure practices for API key handling:
- API key is stored in the auth context (
this.$auth
) and not hardcoded - Key is passed securely in headers using HTTPS
- No exposure of credentials in logs or error messages
- Standard header-based authentication using
X-Api-Key
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for potential API key exposure in other files
rg -i "api[-_]key|apikey" --type js --type ts
# Check for proper auth implementation
ast-grep --pattern 'this.$auth'
Length of output: 67035
Script:
#!/bin/bash
# Check for API key storage and handling patterns
rg -i "api[-_]key|apikey" --type js --type ts -A 5 -B 5 components/ortto/
# Check for auth implementation patterns
ast-grep --pattern 'class $_ {
$$$
$auth() {
$$$
}
$$$
}'
Length of output: 147
Script:
#!/bin/bash
# Check for API key storage and handling patterns in ortto component
rg -i "api[-_]key|apikey" components/ortto/ortto.app.mjs
# Check for auth implementation and headers
rg -i "headers|auth" components/ortto/ortto.app.mjs -A 5 -B 5
# Look for any sensitive data handling patterns
rg -i "sensitive|secret|credentials" components/ortto/
Length of output: 881
components/ortto/actions/create-custom-activity/create-custom-activity.mjs
Show resolved
Hide resolved
There was a problem hiding this 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
🧹 Outside diff range and nitpick comments (3)
components/ortto/ortto.app.mjs (3)
79-85
: ConsolidatecreatePerson
andupdatePerson
methodsBoth
createPerson
andupdatePerson
methods make a POST request to the same endpoint/person/merge
. Consider consolidating these methods into a single method to reduce code duplication and improve maintainability.Alternatively, if there is a logical distinction between creating and updating a person, ensure that the method names and implementations reflect that difference.
81-83
: Remove redundantmethod: "POST"
increatePerson
The
_makeRequest
method already defaults to usingmethod: "POST"
. Includingmethod: "POST"
again increatePerson
is redundant.Consider removing it for consistency, or if clarity is desired, explicitly specify the
method
in all methods.createPerson(opts = {}) { return this._makeRequest({ - method: "POST", path: "/person/merge", ...opts, }); },
86-92
: Ensure consistent specification of HTTP methodsIn the
createCustomActivity
method, you explicitly specifymethod: "POST"
, while other methods rely on the default method in_makeRequest
. For consistency, consider specifying themethod
parameter explicitly in all methods or rely on the default in all cases.This will improve code readability and maintain consistency across your methods.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
components/ortto/ortto.app.mjs
(1 hunks)
🔇 Additional comments (2)
components/ortto/ortto.app.mjs (2)
57-66
: 🛠️ Refactor suggestion
Add request timeout and retry logic to _makeRequest
method
The _makeRequest
method should include timeout and retry logic to enhance reliability and handle potential network issues.
Consider applying the previous suggestion to implement timeout and retry logic:
_makeRequest({
$ = this,
path,
+ timeout = 30000,
+ retries = 3,
...opts
}) {
+ const makeAttempt = async (attempt) => {
+ try {
return await axios($, {
method: "POST",
url: this._baseUrl() + path,
headers: this._headers(),
+ timeout,
...opts,
});
+ } catch (error) {
+ if (attempt < retries && error.response?.status >= 500) {
+ await new Promise(resolve => setTimeout(resolve, 1000 * attempt));
+ return makeAttempt(attempt + 1);
+ }
+ throw error;
+ }
+ };
+ return makeAttempt(1);
},
93-113
: Verify the property name used for pagination
Ensure that the property response.has_more
correctly reflects the API's pagination response. If the API returns hasMore
in camelCase, using has_more
may result in incorrect pagination behavior.
Run the following script to confirm the correct pagination property:
Replace $API_KEY
and $REGION
with your actual API key and region. Check the output to see whether has_more
or hasMore
is present.
✅ Verification successful
Property has_more
is the correct format for Ortto API pagination
Based on the codebase analysis, the usage of response.has_more
in snake_case is correct. This is evidenced by:
- The consistent usage of
has_more
in the Ortto component itself (components/ortto/ortto.app.mjs) - The pattern matches other API integrations that specifically use snake_case for pagination (e.g., Slack Bot component)
- Other components that use camelCase consistently use
hasMore
instead, showing a clear distinction in API conventions (e.g., Sigma, RegFox components)
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify whether the API response uses 'has_more' or 'hasMore' for pagination.
# Make a sample API request
curl -s -X POST \
-H "X-Api-Key: $API_KEY" \
-H "Content-Type: application/json" \
"https://$REGION/v1/person/get" \
-d '{"limit":1,"offset":0}' > response.json
# Extract the top-level keys from the response
jq 'keys' response.json
Length of output: 145
Script:
#!/bin/bash
# Let's search for API response handling patterns in the codebase
rg -U "response\.(has_more|hasMore)" -A 3 -B 3
# Also search for any documentation or type definitions that might indicate the expected response format
fd -e md -e ts -e js -e mjs . -x rg -l "has_more|hasMore"
# Search for actual API response handling
ast-grep --pattern 'const response = await $$$; $$$hasMore$$$'
Length of output: 7978
There was a problem hiding this 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
🧹 Outside diff range and nitpick comments (2)
components/ortto/ortto.app.mjs (2)
73-78
: Explicitly specify the HTTP method inupdatePerson
Currently, the
updatePerson
method does not explicitly set the HTTP method for the request. For clarity and consistency with other methods, consider specifying the HTTP method explicitly.Apply this diff to specify the HTTP method:
updatePerson(opts = {}) { return this._makeRequest({ + method: "POST", path: "/person/merge", ...opts, }); },
99-112
: InitializehasMore
totrue
for clarity inpaginate
methodWhile the
do...while
loop ensures the code executes at least once, initializinghasMore
totrue
enhances readability by clearly indicating that pagination begins with an assumption of more data.Apply this diff for improved clarity:
async *paginate({ fn, data = {}, fieldName, ...opts }) { - let hasMore = false; + let hasMore = true; let page = 0; do { data.limit = LIMIT; data.offset = LIMIT * page++; const response = await fn({ data, ...opts, }); for (const d of response[fieldName]) { yield d; } hasMore = response.has_more; } while (hasMore); },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (1)
components/ortto/ortto.app.mjs
(1 hunks)
🔇 Additional comments (2)
components/ortto/ortto.app.mjs (2)
57-66
: [Duplicate Comment] Add request timeout and retry logic in _makeRequest
As previously suggested, the _makeRequest
method should include timeout and retry logic to enhance reliability and handle transient network issues.
93-113
: Ensure correct handling of pagination in paginate
method
Verify that the pagination logic correctly handles the has_more
field from the API response. Ensure that the field has_more
exists and is properly returned by the API endpoint used in the fn
parameter.
To confirm, run the following script to check the existence of has_more
in the API response:
Expect the output to be true
or false
. If has_more
is not present, adjust the pagination logic accordingly.
✅ Verification successful
Based on the examination of the codebase, I can now generate the final response:
The paginate
method's handling of has_more
field is correctly implemented
The implementation in the Ortto app is safe and correct because:
- The
has_more
field is properly extracted from the API response and used to control pagination - The method yields data from the specified
fieldName
array before checkinghas_more
, ensuring no data is lost - The pagination logic uses standard offset-based pagination with a LIMIT constant
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the 'has_more' field exists in the API response for pagination.
# Replace 'your_api_key' and 'your_region' with actual values or ensure they are correctly set in the environment.
curl -X POST "https://your_region/v1/person/get" \
-H "X-Api-Key: your_api_key" \
-H "Content-Type: application/json" \
-d '{"limit": 1, "offset": 0}' | jq '.has_more'
Length of output: 442
Script:
#!/bin/bash
# Let's search for API endpoints in the codebase that use this paginate method
# and verify the response structure
# First, let's find the base URL or API endpoint configuration
rg -l "ortto" --type js --type mjs
# Then, let's look for actual API calls that use pagination
ast-grep --pattern 'paginate({$$$})'
Length of output: 1588
Script:
#!/bin/bash
# Let's also check the test files to see if there are any test cases
# that demonstrate the expected response structure
rg "has_more" --type js --type mjs -C 2
Length of output: 67
Script:
#!/bin/bash
# Let's examine the Ortto class implementation to understand the API structure
fd "ortto\..*\.(js|mjs)$" --exec cat {}
Length of output: 3182
Script:
#!/bin/bash
# Let's check how this paginate method is used in the codebase
rg -t js -t mjs "paginate\(" -C 5
# Let's also check for any API documentation or examples
fd "README\.md$" --exec cat {}
Length of output: 66514
Script:
#!/bin/bash
# Let's examine the constants file to understand the LIMIT value
fd "constants\..*\.(js|mjs)$" --exec cat {}
Length of output: 47
Script:
#!/bin/bash
# Let's look for any test files related to Ortto
fd "ortto.*\.(test|spec)\.(js|mjs)$" --exec cat {}
Length of output: 54
Script:
#!/bin/bash
# Let's check the common constants file specifically
fd "common/constants\.mjs$" --exec cat {}
# Let's also look for any usage of the paginate method with fieldName
rg -B 2 -A 2 "paginate.*fieldName" --type js --type mjs
# And check for any API response examples or tests
fd "\.(test|spec)\.(js|mjs)$" --exec rg -l "has_more"
Length of output: 185
/approve |
Resolves #13209.
Summary by CodeRabbit
Release Notes
New Features
Improvements
Version Update