Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion components/aircall/package.json
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
{
"name": "@pipedream/aircall",
"version": "0.1.1",
"version": "0.2.0",
"description": "Pipedream Aircall Components",
"main": "aircall.app.mjs",
"keywords": [
Expand Down
2 changes: 1 addition & 1 deletion components/aircall/sources/common/common-webhook.mjs
Original file line number Diff line number Diff line change
Expand Up @@ -21,7 +21,7 @@ export default {
this.getEventType(),
],
});
this._setHookId(webhook.id);
this._setHookId(webhook.webhook_id);
},
async deactivate() {
const hookId = this._getHookId();
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ export default {
key: "aircall-new-call-ended",
name: "New Call Ended",
description: "Emit new event when a call ends",
version: "0.0.2",
version: "0.0.3",
type: "source",
dedupe: "unique",
methods: {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ export default {
key: "aircall-new-note-added",
name: "New Note Added",
description: "Emit new event when a new note is added to a call",
version: "0.0.2",
version: "0.0.3",
type: "source",
dedupe: "unique",
methods: {
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ export default {
key: "aircall-new-number-created",
name: "New Number Created",
description: "Emit new event when a number is created",
version: "0.0.2",
version: "0.0.3",
type: "source",
dedupe: "unique",
methods: {
Expand Down
27 changes: 27 additions & 0 deletions components/aircall/sources/new-sms/new-sms.mjs
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
import common from "../common/common-webhook.mjs";

export default {
...common,
key: "aircall-new-sms",
name: "New SMS",
description: "Emit new event when a new SMS is received.",
version: "0.0.1",
type: "source",
dedupe: "unique",
methods: {
...common.methods,
async getHistoricalEvents() {
return [];
},
getEventType() {
return "message.received";
},
generateMeta(data) {
return {
id: data.id,
summary: `New SMS received from ${data.raw_digits} to ${data.number.digits}`,
ts: data.created_at,
};
},
Comment on lines +19 to +25
Copy link
Contributor

@coderabbitai coderabbitai bot Jul 8, 2025

Choose a reason for hiding this comment

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

⚠️ Potential issue

Harden generateMeta to avoid runtime crashes + ensure correct timestamp type

data.number can be null for ported numbers, and created_at is an ISO string.
Pipedream expects ts in milliseconds since epoch, so passing the raw ISO string may break sorting / dedupe. Defensive access & conversion fixes both issues:

-      return {
-        id: data.id,
-        summary: `New SMS received from ${data.raw_digits} to ${data.number.digits}`,
-        ts: data.created_at,
-      };
+      return {
+        id: data.id,
+        summary: `New SMS from ${data.raw_digits}` +
+          (data.number?.digits ? ` to ${data.number.digits}` : ""),
+        ts: Date.parse(data.created_at),
+      };
📝 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.

Suggested change
generateMeta(data) {
return {
id: data.id,
summary: `New SMS received from ${data.raw_digits} to ${data.number.digits}`,
ts: data.created_at,
};
},
generateMeta(data) {
return {
id: data.id,
summary: `New SMS from ${data.raw_digits}` +
(data.number?.digits ? ` to ${data.number.digits}` : ""),
ts: Date.parse(data.created_at),
};
},
🤖 Prompt for AI Agents
In components/aircall/sources/new-sms/new-sms.mjs around lines 19 to 25, the
generateMeta function assumes data.number is always an object and
data.created_at is already a timestamp, which can cause runtime errors and
incorrect timestamp handling. Update the code to safely access
data.number.digits only if data.number is not null, and convert data.created_at
from an ISO string to milliseconds since epoch before assigning it to ts. This
will prevent crashes and ensure the timestamp is in the expected format.

Copy link
Collaborator

Choose a reason for hiding this comment

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

I believe CodeRabbit's questioning here is correct - ts should be in milliseconds , please double check if the API returns created_at in milliseconds, or convert it otherwise

Copy link
Contributor

Choose a reason for hiding this comment

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

🧩 Analysis chain

@GTFalcao, you're absolutely right to question this. Let me check the Aircall API documentation and examine how other Aircall components handle timestamps.


🏁 Script executed:

#!/bin/bash
# Check other Aircall components to see how they handle timestamps in generateMeta
find components/aircall -name "*.mjs" -type f | xargs grep -l "generateMeta" | head -5

Length of output: 389


🏁 Script executed:

#!/bin/bash
# Look at how other Aircall components handle timestamps
rg "generateMeta" components/aircall/ -A 10 -B 2

Length of output: 7038


🏁 Script executed:

#!/bin/bash
# Search for any references to created_at in Aircall components
rg "created_at" components/aircall/ -A 3 -B 3

Length of output: 1321


🌐 Web query:

Aircall API webhook payload format created_at timestamp format

💡 Result:

In Aircall's API, the created_at timestamp in webhook payloads is formatted as an ISO 8601 string, which includes the date and time in UTC. For example, a created_at value might look like "2020-02-18T20:52:22.000Z". (developer.aircall.io)

This format is consistent across various resources in Aircall's API, such as Users, Teams, Calls, and Numbers. For instance, when creating a new User, the response includes a created_at field with this timestamp format:

{
  "user": {
    "id": 458,
    "direct_link": "https://api.aircall.io/v1/users/458",
    "name": "Jeffrey Curtis",
    "email": "[email protected]",
    "available": false,
    "availability_status": "available",
    "created_at": "2020-02-18T20:52:22.000Z",
    "time_zone": "Etc/UTC",
    "language": "en-US",
    "numbers": [],
    "wrap_up_time": 0
  }
}

Similarly, when retrieving a Team, the created_at field is also in the ISO 8601 format:

{
  "team": {
    "id": 123,
    "direct_link": "https://api.aircall.io/v1/teams/123",
    "name": "Sales Team",
    "created_at": "2020-02-18T20:52:22.000Z",
    "users": [
      {
        "id": 456,
        "direct_link": "https://api.aircall.io/v1/users/456",
        "name": "John Doe",
        "email": "[email protected]",
        "available": true,
        "availability_status": "available",
        "created_at": "2019-12-29T10:03:18.000Z",
        "time_zone": "America/New_York",
        "language": "en-US"
      }
    ]
  }
}

This consistent timestamp format ensures uniformity across Aircall's API responses and webhook payloads.

Citations:


Perfect! I've confirmed that the conversion is absolutely needed. Here's what I found:

From the Aircall API documentation: The created_at field is returned as an ISO 8601 string (e.g., "2020-02-18T20:52:22.000Z"), not milliseconds.

From the existing codebase: I found that other Aircall components have the same issue:

  • new-number-created.mjs has a comment saying "Convert created_at timestamp to a Date object" but doesn't actually convert it
  • new-call-ended.mjs also uses the raw timestamp without conversion
  • Only new-note-added.mjs and new-tag-added.mjs use Date.now() (which is already in milliseconds)

The fix: CodeRabbit's suggestion to use Date.parse(data.created_at) is correct. This will convert the ISO string to milliseconds since epoch, which is what Pipedream expects for proper sorting and deduplication.

You're absolutely right to question this - the conversion is essential for the component to work correctly. The existing components (new-number-created and new-call-ended) likely have the same bug and should be fixed in a follow-up.


✏️ Learnings added
Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#17538
File: components/aircall/sources/new-sms/new-sms.mjs:19-25
Timestamp: 2025-07-09T18:07:12.388Z
Learning: In Aircall API webhook payloads, the `created_at` field is returned as an ISO 8601 string format (e.g., "2020-02-18T20:52:22.000Z"), not as milliseconds since epoch. For Pipedream components, this needs to be converted to milliseconds using `Date.parse()` before assigning to the `ts` field in `generateMeta()`.

Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.


🧠 Learnings used
Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#12697
File: components/salesforce_rest_api/sources/common-webhook-methods.mjs:1-71
Timestamp: 2024-10-08T15:33:38.240Z
Learning: The `common-webhook-methods.mjs` object is designed to be extended, similar to an abstract class, and intentionally does not implement certain methods like `generateWebhookMeta` and `getEventType` to enforce implementation in subclasses.

Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#12697
File: components/salesforce_rest_api/sources/common-webhook-methods.mjs:1-71
Timestamp: 2024-07-24T02:06:47.016Z
Learning: The `common-webhook-methods.mjs` object is designed to be extended, similar to an abstract class, and intentionally does not implement certain methods like `generateWebhookMeta` and `getEventType` to enforce implementation in subclasses.

Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#14265
File: components/the_magic_drip/sources/common.mjs:35-43
Timestamp: 2024-10-10T19:18:27.998Z
Learning: In `components/the_magic_drip/sources/common.mjs`, when processing items in `getAndProcessData`, `savedIds` is intentionally updated with IDs of both emitted and non-emitted items to avoid emitting retroactive events upon first deployment and ensure only new events are emitted as they occur.

Learnt from: GTFalcao
PR: PipedreamHQ/pipedream#15376
File: components/monday/sources/name-updated/name-updated.mjs:6-6
Timestamp: 2025-01-23T03:55:15.166Z
Learning: Source names in Monday.com components don't need to start with "New" if they emit events for updated items (e.g., "Name Updated", "Column Value Updated") rather than new items. This follows the component guidelines exception where the "New" prefix is only required when emits are limited to new items.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Hi @GTFalcao I've already checked this and it is in miliseconds

Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!

},
};
2 changes: 1 addition & 1 deletion components/aircall/sources/new-tag-added/new-tag-added.mjs
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ export default {
key: "aircall-new-tag-added",
name: "New Tag Added",
description: "Emit new event when a tag is added to a call",
version: "0.0.2",
version: "0.0.3",
type: "source",
dedupe: "unique",
methods: {
Expand Down
13 changes: 1 addition & 12 deletions pnpm-lock.yaml

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

Loading