Shopify Draft Order Updated trigger not firing when line items are added/removed

[Osireg17]

WHY

Resolves: #19147 (comment)

Summary by CodeRabbit

• Bug Fixes
  • Updated draft order tracking to reflect when orders were last modified rather than when they were created.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
pipedream-docs-redirect-do-not-edit	Ignored			Nov 23, 2025 10:23pm

[coderabbitai]

Walkthrough

Version bump and metadata generation logic refactor for the Shopify Draft Order Updated trigger source. The generateMeta() function now derives deduplication ID and timestamp from resource.updated_at instead of resource.created_at and resource.id.

Changes

Cohort / File(s)	Summary
Shopify Draft Order Updated Source components/shopify_developer_app/sources/draft-order-updated/draft-order-updated.mjs	Version incremented from 0.0.1 to 0.0.2; generateMeta() refactored to compute timestamp from updated_at rather than created_at, with metadata id field now set to the computed timestamp value instead of resource.id.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

• The change is isolated to a single source file with a focused metadata generation refactor
• Primary concern: verify that deriving id and ts from updated_at correctly resolves the deduplication issue for line item modifications as described in the linked issue
• Confirm the summary field remains correctly based on resource.id for user-facing display

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description only contains a brief reference to the linked issue but lacks substantive explanation of what changes were made and why they fix the problem.	Expand the description to explain the root cause of the issue and describe the technical fix applied (e.g., why switching from created_at to updated_at resolves line item firing).

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly addresses the primary issue: the Shopify Draft Order Updated trigger not firing for line item changes, which matches the changeset's focus on modifying the generateMeta logic.
Linked Issues check	✅ Passed	The changes modify the generateMeta function to use updated_at instead of created_at for timestamps, which should enable the trigger to fire on all draft order updates including line item changes.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to fixing the Shopify Draft Order Updated trigger issue; the version bump and generateMeta modifications are necessary for addressing line item update detection.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

• 📝 Generate docstrings

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: ASSERTIVE

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 76d24db and bb9aa32.

📒 Files selected for processing (1)

• components/shopify_developer_app/sources/draft-order-updated/draft-order-updated.mjs (1 hunks)

🧰 Additional context used

🧬 Code graph analysis (1)

components/shopify_developer_app/sources/draft-order-updated/draft-order-updated.mjs (14)

components/shopify_developer_app/sources/cart-updated/cart-updated.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/inventory-level-updated/inventory-level-updated.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-draft-order/new-draft-order.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-cancelled-order/new-cancelled-order.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-cart-created/new-cart-created.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-order-created/new-order-created.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-fulfillment-event/new-fulfillment-event.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-event-emitted/new-event-emitted.mjs (1)

• ts (33-33)

components/shopify_developer_app/sources/new-order-fulfilled/new-order-fulfilled.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-product-updated/new-product-updated.mjs (1)

• ts (46-46)

components/shopify_developer_app/sources/new-product-created/new-product-created.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-updated-customer/new-updated-customer.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/new-updated-order/new-updated-order.mjs (1)

• ts (17-17)

components/shopify_developer_app/sources/shop-update/shop-update.mjs (1)

• ts (17-17)

🔇 Additional comments (2)

components/shopify_developer_app/sources/draft-order-updated/draft-order-updated.mjs (2)

10-10: LGTM: Appropriate version bump for bug fix.

The patch version increment from 0.0.1 to 0.0.2 correctly reflects the bug fix nature of this change.

---

17-24: Excellent fix that correctly addresses the root cause.

The change from using resource.id to ts (timestamp) as the deduplication ID is the key fix. With the old implementation, all updates to the same draft order shared the same resource.id, causing subsequent updates to be filtered out by the dedupe: "unique" setting. Using resource.updated_at as the deduplication key ensures each update event has a unique ID, allowing line item additions/removals to fire correctly.

This pattern is consistent with other "updated" sources in the codebase (cart-updated, inventory-level-updated, new-updated-order, etc.).

Verification confirmed: The Shopify draft_orders/update webhook payload includes the updated_at field (confirmed in test-event.mjs and Shopify webhook documentation). Shopify's documentation explicitly recommends using updated_at for deduplication to avoid dropped deliveries, validating this approach.

Tip

📝 Customizable high-level summaries are now available in beta!

You can now customize how CodeRabbit generates the high-level summary in your pull requests — including its content, structure, tone, and formatting.

• Provide your own instructions using the high_level_summary_instructions setting.
• Format the summary however you like (bullet lists, tables, multi-section layouts, contributor stats, etc.).
• Use high_level_summary_in_walkthrough to move the summary from the description to the walkthrough section.

Example instruction:

"Divide the high-level summary into five sections:

1. 📝 Description — Summarize the main change in 50–60 words, explaining what was done.
2. 📓 References — List relevant issues, discussions, documentation, or related PRs.
3. 📦 Dependencies & Requirements — Mention any new/updated dependencies, environment variable changes, or configuration updates.
4. 📊 Contributor Summary — Include a Markdown table showing contributions:
   | Contributor | Lines Added | Lines Removed | Files Changed |
5. ✔️ Additional Notes — Add any extra reviewer context.
   Keep each section concise (under 200 words) and use bullet or numbered lists for clarity."

Note: This feature is currently in beta for Pro-tier users, and pricing will be announced later.

---

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

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[pipedream-component-development]

Thank you so much for submitting this! We've added it to our backlog to review, and our team has been notified.

[pipedream-component-development]

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:

• Create components to address specific use cases whenever possible
• Component keys should follow the format app_name_slug-slugified-component-name
• Components should follow the standard directory structure
• Prefer Node.js client libraries to REST APIs
• When making API requests, handle pagination to ensure all data / events are processed
• Use secret props to capture sensitive data
• Props and methods should be defined in app files whenever possible
• Document methods with JS Docs
• Use optional props whenever possible, and set a default value where you can
• Use async options to accept user input wherever possible
• Create subscription webhooks sources (vs polling sources) whenever possible
• Always emit a summary with events
• Use a built-in deduping strategy wherever possible
• When building webhook sources, follow these best practices
• When building polling sources, follow these best practices