Infobip - Enhanced SMS Actions with OpenAPI Auto-Generation #18404
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified. |
|
Thanks for submitting this PR! When we review PRs, we follow the Pipedream component guidelines. If you're not familiar, here's a quick checklist:
|
Xaiid
force-pushed
the
feature/infobip-sms-actions
branch
from
7ce03cf to
5308a8d
Compare
WalkthroughThis PR enhances the Infobip SMS component with OpenAPI-based auto-generation infrastructure, adding 16 new SMS API methods to the core client, 15+ corresponding action modules, and two generator scripts to automate future updates from the official Infobip OpenAPI specification. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer
participant GenApp as generate-app.mjs
participant OpenAPI as OpenAPI Spec
participant AppFile as infobip.app.mjs
participant GenAction as generate-actions.mjs
participant ActionDir as Action Modules
rect rgb(200, 220, 255)
Note over Dev,AppFile: App Generation Flow
Dev->>GenApp: npm run generate-app
GenApp->>OpenAPI: Download spec
OpenAPI-->>GenApp: API endpoints & metadata
GenApp->>GenApp: Parse operationIds, extract params
GenApp->>GenApp: Generate JSDoc + method implementations
GenApp->>AppFile: Inject methods between markers
AppFile-->>GenApp: Confirmed
GenApp->>Dev: Report success & count
end
rect rgb(220, 255, 220)
Note over Dev,ActionDir: Action Generation Flow
Dev->>GenAction: npm run generate-actions
GenAction->>AppFile: Load enhanced methods
GenAction->>OpenAPI: Load OpenAPI spec (fallback to app)
GenAction->>GenAction: Parse JSDoc, map to method names
GenAction->>GenAction: Extract OpenAPI params (path/query/body)
GenAction->>GenAction: Generate action template + props
GenAction->>ActionDir: Write action files (skip duplicates)
ActionDir-->>GenAction: Confirmed
GenAction->>Dev: Report results & next steps
end
rect rgb(255, 240, 200)
Note over Dev,ActionDir: Runtime Flow
Dev->>ActionDir: User invokes action
ActionDir->>ActionDir: Destructure props & extra params
ActionDir->>ActionDir: Build pathQuery/payload from props
ActionDir->>AppFile: Call generated method (e.g., sendSmsMessage)
AppFile->>AppFile: Construct path + encode query params
AppFile->>AppFile: Call _makeRequest
AppFile-->>ActionDir: API response
ActionDir->>ActionDir: Export summary from response.status
ActionDir-->>Dev: Return full response
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Areas requiring extra attention:
Poem
Pre-merge checks and finishing touches❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✨ Finishing touches
🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 15
♻️ Duplicate comments (7)
components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (1)
62-62: Use String() instead of toString().Same issue as in other actions—calling
.toString()on values can fail for objects or arrays. UseString(value)for type safety.- pathQuery.push({ name: key, value: value.toString() }); + pathQuery.push({ name: key, value: String(value) });components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs (2)
24-28: Add prop validation for limit.Same issue as the v3 version—the limit should have min/max validation to match the documented constraint of 1000 maximum.
limit: { type: "integer", label: "Limit", description: "Maximum number of delivery reports to be returned. If not set, the latest 50 records are returned. Maximum limit value is `1000` and you can only access reports for the last 48h.", optional: true, + min: 1, + max: 1000, + default: 50, },
52-64: Simplify redundant pathQuery building logic.Same redundant pattern as in
get-outbound-sms-message-delivery-reports-v3.mjs. Refer to the refactoring suggestion there and inupdate-scheduled-sms-messages-status.mjsto consolidate this logic.components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (2)
12-16: Add prop validation for limit.Same issue as other actions—the limit should have min/max validation to enforce the documented constraint of 1000 maximum.
limit: { type: "integer", label: "Limit", description: "Maximum number of messages to be returned in a response. If not set, the latest 50 records are returned. Maximum limit value is `1000` and you can only access messages for the last 48h.", optional: true, + min: 1, + max: 1000, + default: 50, },
40-50: Extract pathQuery building logic to shared method.This is the same pathQuery construction pattern duplicated across all action files. Consolidating this into a shared method in
infobip.app.mjswould significantly improve maintainability and align with Pipedream's guideline to "Define props and methods in app files whenever possible."Refer to the detailed refactoring suggestion in
update-scheduled-sms-messages-status.mjs(lines 19-34).components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (1)
19-34: Extract pathQuery building logic to shared method.This pathQuery construction pattern is duplicated from
update-scheduled-sms-messages-statusand other actions. Refer to the refactoring suggestion inupdate-scheduled-sms-messages-status.mjs(lines 19-34) to consolidate this logic in the app file.components/infobip/actions/get-outbound-sms-message-logs-v3/get-outbound-sms-message-logs-v3.mjs (1)
106-127: Same code duplication pattern as in get-outbound-sms-message-logs.mjs.This file exhibits the same repetitive pathQuery building pattern (15 consecutive if statements). The refactoring suggestion from the previous action file applies here as well.
🧹 Nitpick comments (16)
components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs (1)
36-39: Consider clarifying the summary message.The summary message uses "Update completed successfully", which is somewhat generic. Since this action specifically reschedules messages, consider using a more descriptive message like "Messages rescheduled successfully" to better reflect the operation performed.
- `Update completed successfully: ${response.status?.description || "Success"}` + `Messages rescheduled successfully: ${response.status?.description || "Success"}`components/infobip/actions/send-sms-message/send-sms-message.mjs (1)
5-8: Name/description consistency.Consider dropping “V2” from the user‑facing name (keep versioning in key/path if needed) and expand the truncated description for clarity. Aligns with the Pipedream component checklist on clear naming/docs.
components/infobip/lib/openapi-generator.mjs (1)
1-88: Consider implementing dynamic OpenAPI parsing or renaming the class.The class name
InfobipOpenAPIGeneratorand method names suggest dynamic generation from an OpenAPI specification, but bothgenerateMethods()andgenerateAllActions()return hardcoded static data. This creates a misleading API surface.Consider one of these approaches:
Implement actual OpenAPI parsing (preferred if this is the intended functionality):
- Fetch the Infobip OpenAPI spec dynamically
- Parse paths, operations, and parameters from the spec
- Generate method descriptors programmatically
Rename to reflect static nature (if dynamic generation isn't needed yet):
- Rename class to
InfobipMethodRegistryorInfobipStaticMethodDefinitions- Update method names to
getMethodDefinitions()andgetActionDefinitions()This would align expectations with the actual implementation and improve maintainability.
components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (2)
27-27: Add type safety for value.toString().Calling
.toString()directly on values can fail if the value is an object, array, or other non-primitive type. UseString(value)instead, which safely handles all types.- pathQuery.push({ name: key, value: value.toString() }); + pathQuery.push({ name: key, value: String(value) });
31-40: Add error handling and improve summary message.The API call lacks error handling, and the summary message is generic. Consider wrapping the call in try-catch and providing more specific feedback.
try { const response = await infobip.updateScheduledSmsMessagesStatus({ $, pathQuery: pathQuery.length > 0 ? pathQuery : undefined, }); $.export( "$summary", `Updated scheduled messages for bulk ID: ${bulkId || 'multiple'}` ); return response; } catch (error) { $.export("$summary", `Failed to update scheduled messages: ${error.message}`); throw error; }components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (1)
24-28: Add prop validation for limit.The description states "Maximum limit value is 1000", but there's no validation to enforce this constraint. According to Pipedream guidelines, props should set default values and validation when applicable.
limit: { type: "integer", label: "Limit", description: "Maximum number of delivery reports to be returned. If not set, the latest 50 records are returned. Maximum limit value is 1000 and you can only access reports for the last 48h", optional: true, + min: 1, + max: 1000, + default: 50, },components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (1)
3-63: Add JSDoc documentation for the action.According to the Pipedream component guidelines provided in the PR objectives, methods should be "documented with JSDoc." None of the action modules in this PR include JSDoc comments.
Consider adding documentation:
/** * Get inbound SMS messages from Infobip. * Fetches messages if unable to receive them in real-time at your endpoint. * * @param {Object} $ - Pipedream step context * @returns {Promise<Object>} API response with inbound messages * @see {@link https://www.infobip.com/docs/api|Infobip API Documentation} */ async run({ $ }) { // ... }Apply similar documentation to all action files in this PR.
As per coding guidelines.
components/infobip/actions/send-sms-messages/send-sms-messages.mjs (2)
4-6: Align action key/name with guidelines and endpoint semantics (plural).
- Key likely should be prefixed with app slug per checklist, and name should be plural for /sms/3/messages.
Proposed change:
- key: "send-sms-messages", - name: "Send SMS message", + key: "infobip-send-sms-messages", + name: "Send SMS Messages",Please confirm whether this repo expects the "infobip-" prefix for action keys. If unprefixed keys are now standard here, keep the prefix off and only update the name.
11-31: Consider first-class multi-recipient support.Endpoint supports many destinations; current props accept a single phoneNumber. Optionally add phoneNumbers: string[] and build destinations accordingly.
Example:
props: { infobip, phoneNumber: { propDefinition: [infobip, "phoneNumber"], optional: false }, + phoneNumbers: { type: "string[]", label: "Phone Numbers", description: "Send to multiple recipients", optional: true }, }, async run({ $ }) { - const { infobip, phoneNumber, text, from, applicationId, entityId, ...params } = this; + const { infobip, phoneNumber, phoneNumbers, text, from, applicationId, entityId, ...params } = this; const response = await infobip.sendSmsMessages({ $, data: { messages: [ { ...(from && { sender: from }), - destinations: [{ to: phoneNumber }], + destinations: (phoneNumbers?.length ? phoneNumbers : [phoneNumber]).map((to) => ({ to })), content: { text }, ...(applicationId && { applicationId }), ...(entityId && { entityId }), }, ], ...params, }, });Also applies to: 34-50
components/infobip/generate-actions.mjs (1)
606-619: Escape quotes/backticks in generated descriptions to avoid broken JS.Descriptions may contain
",`, or backslashes. Escape before template emission.Apply:
- let description = methodInfo.description; + let description = methodInfo.description; if (description.length > 200) { description = description.substring(0, 197) + "..."; } + const safeDescription = description + .replace(/\\/g, "\\\\") + .replace(/"/g, '\\"') + .replace(/`/g, "\\`"); - return `import infobip from "${ACTION_TEMPLATE_PATH}"; + return `import infobip from "${ACTION_TEMPLATE_PATH}"; export default { key: "${actionKey}", name: "${actionName}", description: - "${description} [See the documentation](${methodInfo.externalDoc})", + "${safeDescription} [See the documentation](${methodInfo.externalDoc})",components/infobip/generate-app.mjs (3)
26-54: Add timeout/error guards to OpenAPI download.Network hangs or 30x/40x can stall the CLI. Add request timeout and validate content-type JSON.
Example:
- https.get(CONFIG.openApiUrl, (response) => { + const req = https.get(CONFIG.openApiUrl, (response) => { + response.setTimeout?.(15000, () => req.destroy(new Error("Timeout"))); if (response.statusCode !== 200) { reject(new Error(`HTTP ${response.statusCode}: ${response.statusMessage}`)); return; }
71-83: Consider more resilient operationId transformation.Some specs use underscores or camelCase. Normalize non-alphanumerics to a delimiter before camelizing.
- operationIdToCamelCase(operationId) { + operationIdToCamelCase(operationId) { if (!operationId) return null; - - return operationId - .split("-") + return operationId + .replace(/[^A-Za-z0-9]+/g, "-") + .split("-")
289-309: Marker handling is brittle — document or harden.Finding the end marker by scanning for
"},\n};"is fragile. Either use explicit end marker or AST. At minimum, use the configuredmethodsEndMarker.Also applies to: 314-337
components/infobip/actions/send-sms-messages-over-query-parameters/send-sms-messages-over-query-parameters.mjs (2)
5-7: Synchronize name/description (plural vs singular).Name is plural; description uses singular “Send SMS message…”. Align for clarity.
- name: "Send SMS Messages Over Query Parameters", - description: - "Send SMS message over query parameters ... + name: "Send SMS Messages Over Query Parameters", + description: + "Send SMS messages over query parameters ...
150-157: Application/Entity IDs are defined but not explicitly added — currently rely on rest params.They’re picked up via
paramsand appended to pathQuery (works). Consider destructuring them explicitly for clarity and to avoid accidental shadowing.Also applies to: 159-191
components/infobip/actions/get-outbound-sms-message-logs/get-outbound-sms-message-logs.mjs (1)
94-113: Consider extracting pathQuery building logic into a helper function.The pathQuery building logic (lines 95-107) repeats the same pattern 13 times. While this auto-generated code is functionally correct, a helper function could improve maintainability:
+ const addToPathQuery = (params, pathQuery) => { + Object.entries(params).forEach(([key, value]) => { + if (value !== undefined && value !== null) { + pathQuery.push({ name: key, value: value.toString() }); + } + }); + }; + const pathQuery = []; - if (from !== undefined && from !== null) pathQuery.push({ name: "from", value: from.toString() }); - if (to !== undefined && to !== null) pathQuery.push({ name: "to", value: to.toString() }); - if (bulkId !== undefined && bulkId !== null) pathQuery.push({ name: "bulkId", value: bulkId.toString() }); - if (messageId !== undefined && messageId !== null) pathQuery.push({ name: "messageId", value: messageId.toString() }); - if (generalStatus !== undefined && generalStatus !== null) pathQuery.push({ name: "generalStatus", value: generalStatus.toString() }); - if (sentSince !== undefined && sentSince !== null) pathQuery.push({ name: "sentSince", value: sentSince.toString() }); - if (sentUntil !== undefined && sentUntil !== null) pathQuery.push({ name: "sentUntil", value: sentUntil.toString() }); - if (limit !== undefined && limit !== null) pathQuery.push({ name: "limit", value: limit.toString() }); - if (mcc !== undefined && mcc !== null) pathQuery.push({ name: "mcc", value: mcc.toString() }); - if (mnc !== undefined && mnc !== null) pathQuery.push({ name: "mnc", value: mnc.toString() }); - if (applicationId !== undefined && applicationId !== null) pathQuery.push({ name: "applicationId", value: applicationId.toString() }); - if (entityId !== undefined && entityId !== null) pathQuery.push({ name: "entityId", value: entityId.toString() }); - if (campaignReferenceId !== undefined && campaignReferenceId !== null) pathQuery.push({ name: "campaignReferenceId", value: campaignReferenceId.toString() }); - - Object.entries(params).forEach(([key, value]) => { - if (value !== undefined && value !== null) { - pathQuery.push({ name: key, value: value.toString() }); - } - }); + addToPathQuery({ from, to, bulkId, messageId, generalStatus, sentSince, sentUntil, limit, mcc, mnc, applicationId, entityId, campaignReferenceId, ...params }, pathQuery);Note: Since this is auto-generated code, you may prefer to update the generator script instead of individual action files.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (21)
components/infobip/README.md(1 hunks)components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs(1 hunks)components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs(1 hunks)components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs(1 hunks)components/infobip/actions/get-outbound-sms-message-logs-v3/get-outbound-sms-message-logs-v3.mjs(1 hunks)components/infobip/actions/get-outbound-sms-message-logs/get-outbound-sms-message-logs.mjs(1 hunks)components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs(1 hunks)components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs(1 hunks)components/infobip/actions/log-end-tag/log-end-tag.mjs(1 hunks)components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs(1 hunks)components/infobip/actions/send-binary-sms-message/send-binary-sms-message.mjs(1 hunks)components/infobip/actions/send-sms-message-over-query-parameters/send-sms-message-over-query-parameters.mjs(1 hunks)components/infobip/actions/send-sms-message/send-sms-message.mjs(1 hunks)components/infobip/actions/send-sms-messages-over-query-parameters/send-sms-messages-over-query-parameters.mjs(1 hunks)components/infobip/actions/send-sms-messages/send-sms-messages.mjs(1 hunks)components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs(1 hunks)components/infobip/generate-actions.mjs(1 hunks)components/infobip/generate-app.mjs(1 hunks)components/infobip/infobip.app.mjs(1 hunks)components/infobip/lib/openapi-generator.mjs(1 hunks)components/infobip/package.json(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (18)
components/infobip/actions/send-sms-message/send-sms-message.mjs (2)
components/infobip/actions/send-binary-sms-message/send-binary-sms-message.mjs (2)
params(34-34)response(36-50)components/infobip/actions/send-sms-messages/send-sms-messages.mjs (2)
params(34-34)response(36-50)
components/infobip/generate-app.mjs (14)
components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (1)
response(52-55)components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs (1)
response(66-69)components/infobip/actions/get-outbound-sms-message-logs/get-outbound-sms-message-logs.mjs (1)
response(115-118)components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (1)
response(31-34)components/infobip/actions/log-end-tag/log-end-tag.mjs (1)
response(20-23)components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs (1)
response(31-34)components/infobip/actions/send-binary-sms-message/send-binary-sms-message.mjs (1)
response(36-50)components/infobip/actions/send-sms-message-over-query-parameters/send-sms-message-over-query-parameters.mjs (1)
response(200-203)components/infobip/actions/send-sms-message/send-sms-message.mjs (1)
response(36-50)components/infobip/actions/send-sms-messages-over-query-parameters/send-sms-messages-over-query-parameters.mjs (1)
response(193-196)components/infobip/actions/send-sms-messages/send-sms-messages.mjs (1)
response(36-50)components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (1)
response(31-34)components/infobip/generate-actions.mjs (14)
content(122-122)content(673-673)summary(212-214)summary(574-574)operation(87-87)description(218-221)description(607-607)methodName(208-208)methodName(643-643)methodName(657-657)hasPathParams(236-236)parameters(90-96)methods(686-686)methods(769-769)components/infobip/infobip.app.mjs (16)
path(196-196)path(234-234)path(271-271)path(301-301)path(337-337)path(371-371)path(407-407)path(443-443)path(479-479)path(515-515)path(557-557)path(599-599)path(636-636)path(673-673)path(710-710)path(746-746)
components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (1)
components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (3)
params(50-50)pathQuery(52-52)response(66-69)
components/infobip/infobip.app.mjs (12)
components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (1)
pathQuery(40-40)components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (1)
pathQuery(52-52)components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs (1)
pathQuery(52-52)components/infobip/actions/get-outbound-sms-message-logs-v3/get-outbound-sms-message-logs-v3.mjs (1)
pathQuery(106-106)components/infobip/actions/get-outbound-sms-message-logs/get-outbound-sms-message-logs.mjs (1)
pathQuery(94-94)components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs (1)
pathQuery(22-22)components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (1)
pathQuery(22-22)components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs (1)
pathQuery(22-22)components/infobip/actions/send-sms-message-over-query-parameters/send-sms-message-over-query-parameters.mjs (1)
pathQuery(168-168)components/infobip/actions/send-sms-messages-over-query-parameters/send-sms-messages-over-query-parameters.mjs (1)
pathQuery(162-162)components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (1)
pathQuery(22-22)components/infobip/generate-app.mjs (1)
pathParams(105-105)
components/infobip/actions/send-binary-sms-message/send-binary-sms-message.mjs (2)
components/infobip/actions/send-sms-message/send-sms-message.mjs (2)
params(34-34)response(36-50)components/infobip/actions/send-sms-messages/send-sms-messages.mjs (2)
params(34-34)response(36-50)
components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (2)
components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (3)
params(38-38)pathQuery(40-40)response(52-55)components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs (3)
params(50-50)pathQuery(52-52)response(66-69)
components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs (2)
components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)
components/infobip/generate-actions.mjs (3)
components/infobip/generate-app.mjs (13)
spec(65-65)spec(363-363)parameters(219-219)content(64-64)content(289-289)methodName(231-231)summary(101-101)summary(228-228)description(102-102)hasPathParams(172-172)method(267-267)methods(255-255)methods(366-366)components/infobip/lib/openapi-generator.mjs (1)
methods(9-62)components/infobip/infobip.app.mjs (16)
path(196-196)path(234-234)path(271-271)path(301-301)path(337-337)path(371-371)path(407-407)path(443-443)path(479-479)path(515-515)path(557-557)path(599-599)path(636-636)path(673-673)path(710-710)path(746-746)
components/infobip/actions/send-sms-messages-over-query-parameters/send-sms-messages-over-query-parameters.mjs (1)
components/infobip/actions/send-sms-message-over-query-parameters/send-sms-message-over-query-parameters.mjs (3)
params(166-166)pathQuery(168-168)response(200-203)
components/infobip/actions/get-outbound-sms-message-logs/get-outbound-sms-message-logs.mjs (3)
components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (3)
params(38-38)pathQuery(40-40)response(52-55)components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs (3)
params(50-50)pathQuery(52-52)response(66-69)components/infobip/actions/get-outbound-sms-message-logs-v3/get-outbound-sms-message-logs-v3.mjs (3)
params(104-104)pathQuery(106-106)response(129-132)
components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (3)
components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)
components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (1)
components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)
components/infobip/actions/send-sms-message-over-query-parameters/send-sms-message-over-query-parameters.mjs (3)
components/infobip/actions/send-sms-message/send-sms-message.mjs (2)
params(34-34)response(36-50)components/infobip/actions/send-sms-messages-over-query-parameters/send-sms-messages-over-query-parameters.mjs (3)
params(160-160)pathQuery(162-162)response(193-196)components/infobip/actions/send-sms-messages/send-sms-messages.mjs (2)
params(34-34)response(36-50)
components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs (3)
components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (3)
params(20-20)pathQuery(22-22)response(31-34)
components/infobip/actions/get-outbound-sms-message-logs-v3/get-outbound-sms-message-logs-v3.mjs (2)
components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (3)
params(50-50)pathQuery(52-52)response(66-69)components/infobip/actions/get-outbound-sms-message-logs/get-outbound-sms-message-logs.mjs (3)
params(92-92)pathQuery(94-94)response(115-118)
components/infobip/actions/get-outbound-sms-message-delivery-reports/get-outbound-sms-message-delivery-reports.mjs (2)
components/infobip/actions/get-inbound-sms-messages/get-inbound-sms-messages.mjs (3)
params(38-38)pathQuery(40-40)response(52-55)components/infobip/actions/get-outbound-sms-message-delivery-reports-v3/get-outbound-sms-message-delivery-reports-v3.mjs (3)
params(50-50)pathQuery(52-52)response(66-69)
components/infobip/actions/send-sms-messages/send-sms-messages.mjs (2)
components/infobip/actions/send-binary-sms-message/send-binary-sms-message.mjs (2)
params(34-34)response(36-50)components/infobip/actions/send-sms-message/send-sms-message.mjs (2)
params(34-34)response(36-50)
components/infobip/lib/openapi-generator.mjs (1)
components/infobip/generate-actions.mjs (2)
methods(686-686)methods(769-769)
🔇 Additional comments (12)
components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs (1)
19-29: ****The original review comment mischaracterizes the code. The script results confirm that
reschedule-sms-messagesfollows the exact same pattern as all comparable actions (get-scheduled-sms-messages,get-scheduled-sms-messages-status,update-scheduled-sms-messages-status, etc.)—all of them addbulkIdtopathQueryon line 23 and process genericparamsviaObject.entriesin the subsequent loop. The code is consistent, not inconsistent. Disregard the review comment.Likely an incorrect or invalid review comment.
components/infobip/actions/send-sms-message/send-sms-message.mjs (1)
36-46: Payload structure is correct for V2 endpoint. Verification confirms the app methodsendSmsMessageuses the/sms/2/text/advancedendpoint and the action file payload aligns with V2 specifications: messages with "from", "destinations", and "text" fields are the correct V2 format. V3 (/sms/3/messages) uses "sender" and "content.text" instead, but the action is calling the V2 method, so no adjustment is required.components/infobip/package.json (1)
15-18: LGTM!The script definitions are properly structured and follow standard npm conventions.
components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjs (1)
12-17: Consider making bulkId optional for consistency.The
bulkIdprop is marked as required (optional: false), but similar actions in this PR (e.g.,get-scheduled-sms-messages,get-outbound-sms-message-delivery-reports) definebulkIdas optional. Review the Infobip API documentation to confirm whether this parameter should be required.components/infobip/actions/get-scheduled-sms-messages/get-scheduled-sms-messages.mjs (1)
12-17: Verify if bulkId should be required.Similar to
update-scheduled-sms-messages-status, this action marksbulkIdas required. Confirm with the Infobip API documentation whether this parameter is mandatory for retrieving scheduled messages.components/infobip/actions/send-sms-messages/send-sms-messages.mjs (1)
41-45: Correct v3 payload shape — LGTM.Using sender and content.text matches /sms/3/messages; different from v2 which uses from and text at message level.
components/infobip/generate-actions.mjs (1)
49-67: Confirm action key naming convention (prefixed vs unprefixed).
METHOD_TO_ACTION_KEY_MAPand generatedkeyuse unprefixed names. The checklist suggestsapp_name_slug-slugified-component-name.If the repo is standardizing on unprefixed keys under the app namespace, ignore. Otherwise switch to
infobip-prefix in the generator.Also applies to: 615-617
components/infobip/actions/send-sms-message-over-query-parameters/send-sms-message-over-query-parameters.mjs (2)
42-47: Text likely required for this endpoint.Spec for
/sms/1/text/querytypically requirestext. Confirm and setoptional: falseif so.- text: { + text: { type: "string", label: "Text", description: "Content of the message being sent.", - optional: true, + optional: false, },
18-23: Addsecret: trueto both username and password fields; cannot remove them without breaking this API endpoint.This query-parameter-based endpoint is a legacy API variant that requires basic authentication credentials as query parameters per the OpenAPI specification. While this is not ideal security-wise, it is required by this specific endpoint design. The fields must be marked
secret: trueto protect them in the Pipedream UI. Note: The preferred alternative is thesend-smsaction, which uses the app's API key authentication instead.username: { type: "string", label: "Username", description: "Username for authentication.", + secret: true, optional: false, }, password: { type: "string", label: "Password", description: "Password for authentication.", + secret: true, optional: false, },components/infobip/actions/log-end-tag/log-end-tag.mjs (1)
3-31: LGTM!The action implementation is clean and follows Pipedream conventions. The pathParams array construction and API method invocation are correct.
components/infobip/actions/get-scheduled-sms-messages-status/get-scheduled-sms-messages-status.mjs (1)
3-42: LGTM!The implementation is clean and follows the established pattern. The defensive null check for the required
bulkIdparameter doesn't hurt and provides an extra safety layer.components/infobip/infobip.app.mjs (1)
171-758: Auto-generated methods look solid overall.The 16 new SMS API methods follow a consistent pattern with proper:
- Query parameter encoding via
encodeURIComponent- Optional chaining for pathQuery iteration
- JSDoc documentation
- HTTP method and path configuration
The code is well-structured for auto-generated content, aside from the
pathParamsissue noted separately.
| const pathQuery = []; | ||
| if (bulkId !== undefined && bulkId !== null) pathQuery.push({ name: "bulkId", value: bulkId.toString() }); | ||
| if (messageId !== undefined && messageId !== null) pathQuery.push({ name: "messageId", value: messageId.toString() }); | ||
| if (limit !== undefined && limit !== null) pathQuery.push({ name: "limit", value: limit.toString() }); | ||
| if (entityId !== undefined && entityId !== null) pathQuery.push({ name: "entityId", value: entityId.toString() }); | ||
| if (applicationId !== undefined && applicationId !== null) pathQuery.push({ name: "applicationId", value: applicationId.toString() }); | ||
| if (campaignReferenceId !== undefined && campaignReferenceId !== null) pathQuery.push({ name: "campaignReferenceId", value: campaignReferenceId.toString() }); | ||
|
|
||
| Object.entries(params).forEach(([key, value]) => { | ||
| if (value !== undefined && value !== null) { | ||
| pathQuery.push({ name: key, value: value.toString() }); | ||
| } | ||
| }); |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Simplify redundant pathQuery building logic.
Lines 53-58 explicitly check each known prop, then lines 60-64 iterate over remaining params. This is redundant—the loop in lines 60-64 would handle all params, making the explicit checks unnecessary.
Either:
- Remove the explicit checks and rely solely on the loop (simpler), or
- Extract this entire pattern to a shared method as suggested in
update-scheduled-sms-messages-status.mjs
Option 2 is preferred to eliminate duplication across all action files.
| description: | ||
| "Reschedule SMS messages Change the date and time of already [scheduled messages](https://www.infobip.com/docs/sms/sms-over-api#schedule-sms). To schedule a message, use the `sendAt` field when [sen... [See the documentation](https://www.infobip.com/docs/sms)", |
There was a problem hiding this comment.
Fix the truncated description.
The description appears to be cut off mid-sentence with "sen...", which diminishes clarity and professionalism. This likely stems from the auto-generation script.
Please complete the description text or adjust the generation script to avoid truncation.
🤖 Prompt for AI Agents
In
components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs
around lines 6-7, the description is truncated ("sen..."); replace it with a
complete sentence such as: "Reschedule SMS messages: Change the date and time of
already scheduled messages. To schedule a message, use the `sendAt` field when
sending messages; see the documentation
(https://www.infobip.com/docs/sms/sms-over-api#schedule-sms) for details."
Ensure the full description fits the file's formatting and update the generation
script if this truncation recurs.
| props: { | ||
| infobip, | ||
| bulkId: { | ||
| type: "string", | ||
| label: "Bulk Id", | ||
| description: "bulkId parameter", | ||
| optional: false, | ||
| } | ||
| }, |
There was a problem hiding this comment.
🧩 Analysis chain
Missing request body props for reschedule operation.
Rescheduling SMS messages typically requires a request body with the new sendAt timestamp. This action only defines query parameters but lacks props for the request body data.
Additionally, bulkId is marked as optional: false (required), yet line 23 conditionally checks if it exists, suggesting it should be optional.
Run the following script to verify the Infobip API requirements and compare with other reschedule/update actions:
🏁 Script executed:
#!/bin/bash
# Description: Check the rescheduleSmsMessages method signature and compare with similar actions
# Check the app file for the rescheduleSmsMessages method implementation
ast-grep --pattern 'rescheduleSmsMessages($$$) {
$$$
}'
# Compare with similar update actions to see if they pass body data
rg -nP -A10 'async run\(\{ \$ \}\)' components/infobip/actions/update-scheduled-sms-messages*/Length of output: 1582
🏁 Script executed:
#!/bin/bash
# Get the full reschedule-sms-messages.mjs file to see all props and implementation
cat components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs
# Also check the Infobip SDK to understand the rescheduleSmsMessages method signature
rg -nP 'rescheduleSmsMessages' --type=js --type=mjsLength of output: 1323
🏁 Script executed:
#!/bin/bash
# Check the Infobip app wrapper to understand the SDK
cat components/infobip/infobip.app.mjs | head -100
# Also search for any other reschedule or update actions for comparison
fd -e mjs -e js components/infobip/actions | grep -E '(reschedule|update)' | head -10Length of output: 3432
🏁 Script executed:
#!/bin/bash
# Search for rescheduleSmsMessages method in infobip.app.mjs
rg -nA20 'rescheduleSmsMessages' components/infobip/infobip.app.mjs
# Find other reschedule/update actions
fd . components/infobip/actions -type f -name '*.mjs' | grep -E '(reschedule|update)'
# Look at an update action for comparison
cat components/infobip/actions/update-scheduled-sms-messages-status/update-scheduled-sms-messages-status.mjsLength of output: 2211
🌐 Web query:
Infobip rescheduleSmsMessages API PUT /sms/1/bulks parameters
💡 Result:
Summary — PUT /sms/1/bulks (reschedule)
-
Query parameter:
- bulkId (string) — the bulk identifier of the scheduled messages to reschedule. [1][2]
-
Request body (JSON):
- sendAt (string) — new send date/time for the bulk. Use format yyyy-MM-dd'T'HH:mm:ss.SSSZ (example: 2025-05-19T11:15:00.000+0000). The new date cannot be later than 180 days from now. Body should contain only sendAt when rescheduling. [1][2]
-
Required scope / permissions: sms:manage (API key must have proper SMS management scope). [3]
-
Example (curl):
- PUT https://{baseUrl}/sms/1/bulks?bulkId=your-bulk-id
- Header: Authorization: {API_key}, Content-Type: application/json
- Body: { "sendAt": "2025-11-15T10:00:00.000+0000" }. [1][2]
Sources:
[1] Infobip — Schedule an SMS / Reschedule (tutorial & docs).
[2] Infobip — SMS API / Send & schedule examples.
[3] Blink (integration docs referencing Infobip reschedule and required scope).
Missing sendAt prop in request body—action cannot function.
The Infobip API requires a sendAt parameter in the request body (format: yyyy-MM-dd'T'HH:mm:ss.SSSZ) to reschedule messages. This action defines only bulkId and lacks the sendAt prop entirely.
Additionally, the SDK method rescheduleSmsMessages only supports query parameters and does not send a request body, preventing sendAt from being passed to the API even if defined as a prop.
Required fixes:
- Add
sendAtprop with type"string", label, and description - Verify the SDK method supports passing request body data (currently it only handles
pathQuery)
🤖 Prompt for AI Agents
In
components/infobip/actions/reschedule-sms-messages/reschedule-sms-messages.mjs
around lines 10 to 18, the action only defines bulkId and is missing the
required sendAt property and also currently uses an SDK method that only sends
query/path params so sendAt never reaches Infobip. Add a new prop "sendAt" with
type "string", appropriate label and description (expecting format
yyyy-MM-dd'T'HH:mm:ss.SSSZ), and then change the call to the Infobip client to
send a request body containing { sendAt } (either by using the SDK method that
accepts a body or by invoking the underlying HTTP client/endpoint and passing
bulkId as query/path and sendAt in the JSON body); optionally validate sendAt
format before sending.
| description: | ||
| "Send binary SMS message Send single or multiple binary messages to one or more destination address. The API response will not contain the final delivery status, use [Delivery Reports](https://www.i... [See the documentation](https://www.infobip.com/docs/sms)", |
There was a problem hiding this comment.
Fix the truncated description.
The description is incomplete and ends with "...". Please provide the full description text.
🤖 Prompt for AI Agents
In
components/infobip/actions/send-binary-sms-message/send-binary-sms-message.mjs
around lines 6 to 7, the description string is truncated with "..." — replace it
with a complete sentence such as: "Send binary SMS messages: send single or
multiple binary messages to one or more destination addresses. The API response
will not contain the final delivery status; use Delivery Reports
(https://www.infobip.com/docs/sms) to receive delivery notifications. See the
documentation (https://www.infobip.com/docs/sms) for full details." Ensure the
description is a single coherent string without ellipses and includes the
Delivery Reports and documentation links.
| text: { | ||
| propDefinition: [infobip, "text"], | ||
| optional: false, | ||
| }, |
There was a problem hiding this comment.
Binary SMS should use binary field, not text.
This action is designed to send binary SMS messages, but it uses a text field (line 43) which is appropriate for text messages, not binary content. According to Infobip's SMS API, binary messages require a binary object containing hex (hexadecimal representation of binary content) and dataCoding fields instead of a plain text field.
Consider restructuring the props and payload:
- text: {
- propDefinition: [infobip, "text"],
- optional: false,
- },
+ hex: {
+ type: "string",
+ label: "Hex Content",
+ description: "Hexadecimal representation of the binary content",
+ optional: false,
+ },
+ dataCoding: {
+ type: "integer",
+ label: "Data Coding",
+ description: "Binary content data coding. Default is 0 (GSM7).",
+ optional: true,
+ default: 0,
+ },And update the payload construction:
- const { infobip, phoneNumber, text, from, applicationId, entityId, ...params } = this;
+ const { infobip, phoneNumber, hex, dataCoding, from, applicationId, entityId, ...params } = this;
const response = await infobip.sendBinarySmsMessage({
$,
data: {
messages: [
{
destinations: [{ to: phoneNumber }],
...(from && { from }),
- text,
+ binary: {
+ hex,
+ dataCoding,
+ },
...(applicationId && { applicationId }),
...(entityId && { entityId }),
},
],
...params,
},
});Also applies to: 43-43
| // Extract properties from schema | ||
| if (schema && schema.properties) { | ||
| extractSchemaProperties(schema.properties, parameters.bodyParams, ""); | ||
| } | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Honor JSON Schema required fields when generating props.
required is never set, so all generated props become optional. Use the parent schema’s required array (and nested objects’ required) to set optional: false.
Apply:
- if (schema && schema.properties) {
- extractSchemaProperties(schema.properties, parameters.bodyParams, "");
- }
+ if (schema && schema.properties) {
+ const requiredList = Array.isArray(schema.required) ? schema.required : [];
+ extractSchemaProperties(schema.properties, parameters.bodyParams, "", requiredList);
+ }And update the helper:
-function extractSchemaProperties(properties, result, prefix = "") {
+function extractSchemaProperties(properties, result, prefix = "", requiredList = []) {
for (const [key, prop] of Object.entries(properties)) {
const fullKey = prefix ? `${prefix}.${key}` : key;
+ const isRequiredHere = Array.isArray(requiredList) && requiredList.includes(key);
if (prop.type === "object" && prop.properties) {
- extractSchemaProperties(prop.properties, result, fullKey);
+ const childRequired = Array.isArray(prop.required) ? prop.required : [];
+ extractSchemaProperties(prop.properties, result, fullKey, childRequired);
} else if (prop.type === "array" && prop.items && prop.items.properties) {
- extractSchemaProperties(prop.items.properties, result, `${fullKey}[]`);
+ const childRequired = Array.isArray(prop.items.required) ? prop.items.required : [];
+ extractSchemaProperties(prop.items.properties, result, `${fullKey}[]`, childRequired);
} else {
result[fullKey] = {
type: prop.type || "string",
description: prop.description || "",
- required: false, // Will be set based on parent schema's required array
+ required: !!isRequiredHere,
enum: prop.enum || null,
example: prop.example || null,
};
}
}
}Also applies to: 152-170
🤖 Prompt for AI Agents
In components/infobip/generate-actions.mjs around lines 141-145 (and similarly
152-170), the code never respects JSON Schema "required" so every generated prop
is marked optional; update the call to extractSchemaProperties to pass the
parent schema.required (e.g., extractSchemaProperties(schema.properties,
parameters.bodyParams, "", schema.required || [])), then modify the helper to
accept a required array parameter, check each property name against that array
and set optional: false when present (optional: true otherwise), and when
recursing into nested object properties pass the nested schema's required array
(childSchema.required || []) so nested required fields are also honored.
| if (openApiParams?.bodyParams) { | ||
| const skipParams = new Set(['messages', 'to', 'text', 'from', 'applicationId', 'entityId']); | ||
| Object.keys(openApiParams.bodyParams).forEach(key => { | ||
| if (!key.includes('[]') && !skipParams.has(key)) { | ||
| paramNames.add(key); | ||
| } | ||
| }); | ||
| } | ||
|
|
||
| // Build destructuring assignment | ||
| if (paramNames.size > 0) { | ||
| destructuring += ", " + Array.from(paramNames).join(", "); | ||
| } | ||
| destructuring += ", ...params } = this;"; | ||
|
|
There was a problem hiding this comment.
Bug: dotted body keys added to destructuring cause invalid JS; also unnecessary.
Body schema keys may include dots (nested), producing const { foo.bar } = this; syntax errors. Avoid adding body params to destructuring.
Apply:
- // Add other body parameters
- if (openApiParams?.bodyParams) {
- const skipParams = new Set(['messages', 'to', 'text', 'from', 'applicationId', 'entityId']);
- Object.keys(openApiParams.bodyParams).forEach(key => {
- if (!key.includes('[]') && !skipParams.has(key)) {
- paramNames.add(key);
- }
- });
- }
+ // Do not add body parameters to destructuring to avoid invalid identifiers (e.g., dotted paths).Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In components/infobip/generate-actions.mjs around lines 452-466, remove the
logic that adds openApiParams.bodyParams into the destructuring (body keys can
contain dots and should not be destructured), and instead build the
destructuring by assembling an array of safe identifiers: start with existing
top-level param names, do not iterate or include any bodyParams keys, always
append '...params' as the last entry, then join the identifiers with ', ' inside
the braces so you never produce invalid leading/trailing commas or invalid
dotted identifiers.
| } else if (openApiParams?.bodyParams && Object.keys(openApiParams.bodyParams).length > 0) { | ||
| // Method with body parameters | ||
| methodCall = ` | ||
| const response = await infobip.${methodName}({ | ||
| $, | ||
| data: { | ||
| ${Array.from(paramNames).filter(name => !['infobip'].includes(name)).map(name => `...(${name} !== undefined && { ${name} }),`).join('\n ')} | ||
| ...params, | ||
| }, | ||
| });`; |
There was a problem hiding this comment.
Bug: query/path names end up in request body. Send only declared body fields.
Current code spreads all destructured names into data, which can inject query/path params into the body.
Apply:
- const response = await infobip.${methodName}({
- $,
- data: {
- ${Array.from(paramNames).filter(name => !['infobip'].includes(name)).map(name => `...(${name} !== undefined && { ${name} }),`).join('\n ')}
- ...params,
- },
- });
+ const response = await infobip.${methodName}({
+ $,
+ // After excluding path/query via destructuring, the rest are body props
+ data: params,
+ });This pairs with the previous change (no body keys in destructuring) so params is the body-only set.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| } else if (openApiParams?.bodyParams && Object.keys(openApiParams.bodyParams).length > 0) { | |
| // Method with body parameters | |
| methodCall = ` | |
| const response = await infobip.${methodName}({ | |
| $, | |
| data: { | |
| ${Array.from(paramNames).filter(name => !['infobip'].includes(name)).map(name => `...(${name} !== undefined && { ${name} }),`).join('\n ')} | |
| ...params, | |
| }, | |
| });`; | |
| } else if (openApiParams?.bodyParams && Object.keys(openApiParams.bodyParams).length > 0) { | |
| // Method with body parameters | |
| methodCall = ` | |
| const response = await infobip.${methodName}({ | |
| $, | |
| // After excluding path/query via destructuring, the rest are body props | |
| data: params, | |
| });`; |
🤖 Prompt for AI Agents
In components/infobip/generate-actions.mjs around lines 557 to 566, the code
currently spreads all destructured param names into the request body which can
accidentally include query/path params; replace the dynamic spread of
Array.from(paramNames)... so the generated data object contains only the
declared body fields (i.e. spread only params which is guaranteed to be
body-only) — remove the per-name spreads and emit data: { ...params } (or
explicitly map only openApiParams.bodyParams keys into the data object) while
keeping $ as before.
| logEndTag(opts = {}) { | ||
| const { pathParams, pathQuery, ...rest } = opts; | ||
| // Example of paths: | ||
| // * /ct/1/log/end/{messageId} | ||
| // * /sms/3/messages | ||
| //* /whatsapp/{versionId}/message/template/{templateName} | ||
| let path = `/ct/1/log/end/{messageId}`; | ||
| pathParams.forEach(({ name, value }) => { | ||
| path = path.replace(`{${name}}`, value); | ||
| }); | ||
|
|
||
| pathQuery?.forEach(({ name, value }) => { | ||
| const separator = path.includes("?") ? "&" : "?"; | ||
| path += `${separator}${name}=${encodeURIComponent(value)}`; | ||
| }); | ||
|
|
||
| return this._makeRequest({ | ||
| method: "POST", | ||
| path, | ||
| ...rest, | ||
| }); | ||
| }, |
There was a problem hiding this comment.
Missing optional chaining for pathParams.
Line 558 uses pathParams.forEach without optional chaining, unlike all other methods in this file which use pathQuery?.forEach. This inconsistency could cause a runtime error if pathParams is undefined or null.
Apply this diff to fix the inconsistency:
- pathParams.forEach(({ name, value }) => {
+ pathParams?.forEach(({ name, value }) => {
path = path.replace(`{${name}}`, value);
});This ensures defensive coding and consistency with the rest of the codebase.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| logEndTag(opts = {}) { | |
| const { pathParams, pathQuery, ...rest } = opts; | |
| // Example of paths: | |
| // * /ct/1/log/end/{messageId} | |
| // * /sms/3/messages | |
| //* /whatsapp/{versionId}/message/template/{templateName} | |
| let path = `/ct/1/log/end/{messageId}`; | |
| pathParams.forEach(({ name, value }) => { | |
| path = path.replace(`{${name}}`, value); | |
| }); | |
| pathQuery?.forEach(({ name, value }) => { | |
| const separator = path.includes("?") ? "&" : "?"; | |
| path += `${separator}${name}=${encodeURIComponent(value)}`; | |
| }); | |
| return this._makeRequest({ | |
| method: "POST", | |
| path, | |
| ...rest, | |
| }); | |
| }, | |
| logEndTag(opts = {}) { | |
| const { pathParams, pathQuery, ...rest } = opts; | |
| // Example of paths: | |
| // * /ct/1/log/end/{messageId} | |
| // * /sms/3/messages | |
| //* /whatsapp/{versionId}/message/template/{templateName} | |
| let path = `/ct/1/log/end/{messageId}`; | |
| pathParams?.forEach(({ name, value }) => { | |
| path = path.replace(`{${name}}`, value); | |
| }); | |
| pathQuery?.forEach(({ name, value }) => { | |
| const separator = path.includes("?") ? "&" : "?"; | |
| path += `${separator}${name}=${encodeURIComponent(value)}`; | |
| }); | |
| return this._makeRequest({ | |
| method: "POST", | |
| path, | |
| ...rest, | |
| }); | |
| }, |
🤖 Prompt for AI Agents
In components/infobip/infobip.app.mjs around lines 551 to 572, the code calls
pathParams.forEach without optional chaining which can throw if pathParams is
undefined; change that call to use optional chaining (pathParams?.forEach(...))
so it safely no-ops when pathParams is null/undefined, matching the existing
defensive pattern used for pathQuery and keeping behavior otherwise identical.
| ```bash | ||
| # Generate enhanced app with OpenAPI methods | ||
| npm run generate-infobip-enhanced-app | ||
|
|
||
| # Generate action components from OpenAPI spec | ||
| npm run generate-infobip-actions | ||
| ``` |
There was a problem hiding this comment.
Fix script names to match package.json.
The script names in the documentation don't match the actual npm scripts defined in package.json.
Apply this diff:
```bash
# Generate enhanced app with OpenAPI methods
-npm run generate-infobip-enhanced-app
+npm run generate-app
# Generate action components from OpenAPI spec
-npm run generate-infobip-actions
+npm run generate-actions
<details>
<summary>🤖 Prompt for AI Agents</summary>
In components/infobip/README.md around lines 44 to 50, the documented npm script
names are incorrect; update the README to use the actual scripts from
package.json by replacing "npm run generate-infobip-enhanced-app" with "npm run
generate-app" and "npm run generate-infobip-actions" with "npm run
generate-actions" so the commands in the docs match the package.json.
</details>
<!-- This is an auto-generated comment by CodeRabbit -->
4 participants
Resolves #18403
Enhanced Infobip component with 16 auto-generated methods from OpenAPI specification v3.43.0
Added automatic generation scripts (generate-app, generate-actions) that parse OpenAPI specs to create actions with up to 24 query parameters, proper prop definitions, and clean naming scheme, eliminating integration errors and improving developer experience.
New I16 auto-generated actions from Infobip OpenAPI specification v3.43.0
Added npm scripts for automated generation: generate-app and generate-actions
Updated component structure with automated OpenAPI specification caching
Bumped component version to support new auto-generation capabilities
Summary by CodeRabbit
Release Notes
New Features
Documentation
Chores