Skip to content

Conversation

@michelle0927
Copy link
Collaborator

@michelle0927 michelle0927 commented Sep 25, 2025

Resolves #18465

The query object prop in the list-conversations endpoint only supports filtering by "statuses". However, we can limit pagination by exiting the loop when we get to a timestamp older than lastTs.

Summary by CodeRabbit

  • Improvements

    • Event feeds now retrieve the most recent items first for conversation state changes and tags.
    • Initial sync behavior refined with updated timestamp handling for more accurate first fetches.
    • Pagination is more efficient when filters are applied, reducing unnecessary requests.
  • Chores

    • Bumped package and source versions to latest patch levels.
    • Updated a description link to point to the correct events documentation.

@vercel
Copy link

vercel bot commented Sep 25, 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 Sep 25, 2025 8:49pm
pipedream-docs-redirect-do-not-edit Ignored Ignored Sep 25, 2025 8:49pm

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Sep 25, 2025

Pre-merge checks and finishing touches

❌ Failed checks (2 warnings, 1 inconclusive)
Check name Status Explanation Resolution
Out of Scope Changes Check ⚠️ Warning The PR includes updates to “new-conversation-state-change” and “new-conversation-tag” sources by adding sorting parameters and version bumps which are not referenced in issue #18465 objectives focused solely on pagination for “New Conversation Created” and “New Message Template Created” sources. Please isolate or remove changes unrelated to the linked issue, or document their purpose in a separate PR to maintain clear scope alignment.
Description Check ⚠️ Warning The pull request description does not follow the repository template because it omits the “## WHY” section heading and fails to explain the rationale and context required by the template. It only states a brief fix and a reference to the endpoint without the structured explanation. Please update the description to include the “## WHY” section and clearly outline the reason for the change, how it addresses the linked issue, and the key behaviors altered by this PR.
Title Check ❓ Inconclusive The title “FrontApp source improvements” is overly generic and does not clearly summarize the main change of applying timestamp filtering to prevent indefinite pagination in FrontApp sources. It fails to convey the key fix or affected components at a glance. Consider revising the title to explicitly reference the pagination fix and timestamp filtering, such as “Apply timestamp filtering to FrontApp sources to prevent indefinite pagination.”
✅ Passed checks (2 passed)
Check name Status Explanation
Linked Issues Check ✅ Passed The changes to base.mjs remove the arbitrary initial timestamp and introduce an early loop break based on the provided filter function, which ensures timestamp filtering is applied during resource fetching. This directly addresses the objectives of issue #18465 by preventing indefinite pagination while preserving correct event emission for the affected sources.
Docstring Coverage ✅ Passed No functions found in the changes. Docstring coverage check skipped.
✨ Finishing touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch issue-18465

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/frontapp/sources/new-conversation-created/new-conversation-created.mjs (1)

33-38: Avoid missing items with identical timestamps

Use >= so items created in the same second as lastTs aren’t skipped.

Apply this diff:

-      await this.startEvent(25, (item, lastTs) => this._getItemTs(item) > lastTs);
+      await this.startEvent(25, (item, lastTs) => this._getItemTs(item) >= lastTs);
-    await this.startEvent(0, (item, lastTs) => this._getItemTs(item) > lastTs);
+    await this.startEvent(0, (item, lastTs) => this._getItemTs(item) >= lastTs);
components/frontapp/sources/new-message-template-created/new-message-template-created.mjs (1)

33-38: Avoid missing templates with same-second timestamps

Use >= to include items with the same created_at as lastTs; “unique” dedupe prevents re-emits.

Apply this diff:

-      await this.startEvent(25, (item, lastTs) => this._getItemTs(item) > lastTs);
+      await this.startEvent(25, (item, lastTs) => this._getItemTs(item) >= lastTs);
-    await this.startEvent(0, (item, lastTs) => this._getItemTs(item) > lastTs);
+    await this.startEvent(0, (item, lastTs) => this._getItemTs(item) >= lastTs);
🧹 Nitpick comments (2)
components/frontapp/sources/common/base.mjs (1)

46-47: Sort using _getItemTs to avoid field coupling

Minor: sort via helper to centralize timestamp logic.

Apply this diff:

-          responseArray.sort((a, b) => b.created_at - a.created_at);
+          responseArray.sort((a, b) => this._getItemTs(b) - this._getItemTs(a));
components/frontapp/sources/new-conversation-state-change/new-conversation-state-change.mjs (1)

31-33: Sorting params LGTM; verify after/field alignment

You sort by created_at and filter with q[after] = lastTs, but emit ts uses emitted_at. Confirm that q[after] applies to created_at vs emitted_at to avoid gaps/duplicates. Consider aligning ts to the filtered field if needed.

If docs confirm q[after] filters on created_at, consider using created_at in _getEmit for ts to keep lastTs consistent.

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a2d4747 and 524d196.

📒 Files selected for processing (6)
  • components/frontapp/package.json (1 hunks)
  • components/frontapp/sources/common/base.mjs (2 hunks)
  • components/frontapp/sources/new-conversation-created/new-conversation-created.mjs (1 hunks)
  • components/frontapp/sources/new-conversation-state-change/new-conversation-state-change.mjs (2 hunks)
  • components/frontapp/sources/new-conversation-tag/new-conversation-tag.mjs (2 hunks)
  • components/frontapp/sources/new-message-template-created/new-message-template-created.mjs (1 hunks)
⏰ 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: Lint Code Base
  • GitHub Check: Publish TypeScript components
  • GitHub Check: Verify TypeScript components
🔇 Additional comments (8)
components/frontapp/package.json (1)

3-3: Version bump LGTM

No behavioral changes. Safe to publish.

components/frontapp/sources/new-conversation-created/new-conversation-created.mjs (2)

9-9: Version bump LGTM


19-21: sort_by created_at unsupported—use client‐side sorting or q filters
The Front Conversations endpoint doesn’t accept sort_by=created_at; it always orders by last‐activity ("date"). To paginate by creation time, fetch pages sorted by "date" then sort or filter locally on conversation.created_at, or use the q[before]/q[after]/q[during] filters on message timestamps.

Likely an incorrect or invalid review comment.

components/frontapp/sources/new-message-template-created/new-message-template-created.mjs (1)

9-9: Version bump LGTM

components/frontapp/sources/common/base.mjs (2)

17-18: Good: remove arbitrary initial timestamp

Defaulting to 0 addresses the 2001-epoch issue and is predictable.


39-41: Early-break requires order by the same timestamp used in filterFn

This break is correct only if iteration is sorted by the same field used in filterFn (created_at). Ensure all sources using filterFn set sort_by=created_at desc; otherwise, you can miss newer items.

components/frontapp/sources/new-conversation-tag/new-conversation-tag.mjs (1)

9-9: Version bump LGTM

components/frontapp/sources/new-conversation-state-change/new-conversation-state-change.mjs (1)

9-10: Doc URL and version bump LGTM

@vunguyenhung vunguyenhung merged commit 00c7b5a into master Sep 30, 2025
10 checks passed
@vunguyenhung vunguyenhung deleted the issue-18465 branch September 30, 2025 05:16
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] FrontApp sources can paginate indefinitely

4 participants