Skip to content

Add Stadium app integration with actions#21227

Open
Garvshah01 wants to merge 2 commits into
PipedreamHQ:masterfrom
SnackMagic:add-stadium-app
Open

Add Stadium app integration with actions#21227
Garvshah01 wants to merge 2 commits into
PipedreamHQ:masterfrom
SnackMagic:add-stadium-app

Conversation

@Garvshah01

@Garvshah01 Garvshah01 commented Jun 23, 2026

Copy link
Copy Markdown

Introduce the Stadium Pipedream app with client credentials auth and actions for stores, orders, points, shipments, and automations.

Summary

Checklist

Please check the following items before your PR can be reviewed:

Versioning

  • All components updated in this PR had their version updated (0.0.1 for new ones)
  • The app updated in this PR had its package.json's version updated

New app

If this is a new app, please submit an app integration request - the PR will only be reviewed after the app is integrated.

  • The app updated in this PR is already integrated

CodeRabbit review

After the PR is opened, and if new changes are pushed, CodeRabbit will automatically review it. Do not 'mark as resolved' CodeRabbit's comments, but reply to them instead, whether you agree (and update the PR accordingly) or disagree.

  • I have addressed or acknowledged all of CodeRabbit's review comments

Summary by CodeRabbit

New Features

  • Stadium platform integration is now available in Pipedream.
  • Added actions to list stores, get store products, retrieve user profiles, create and checkout orders, fetch order details, and check shipment status.
  • Added actions to send points and to create automation orders with order status monitoring.

Documentation

  • Added a comprehensive Stadium integration guide covering setup, sandbox usage, platform limitations, and troubleshooting.

Introduce the Stadium Pipedream app with client credentials auth and actions for stores, orders, points, shipments, and automations.

Co-authored-by: Cursor <cursoragent@cursor.com>
@vercel

vercel Bot commented Jun 23, 2026

Copy link
Copy Markdown

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

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
pipedream-docs-redirect-do-not-edit Ignored Ignored Jun 24, 2026 2:32am

Request Review

@pipedream-component-development

Copy link
Copy Markdown
Collaborator

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

Copy link
Copy Markdown
Collaborator

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:

@coderabbitai

coderabbitai Bot commented Jun 23, 2026

Copy link
Copy Markdown
Contributor

Review Change Stack

📝 Walkthrough

Walkthrough

This PR adds a complete new Pipedream integration for the Stadium platform. It introduces a core app module (stadium.app.mjs) with OAuth client-credentials authentication, a central axios request wrapper, and API method implementations, plus ten action modules covering store catalog, order creation, checkout, order status queries, and automation order management. A README and package.json are also included.

Changes

Stadium Integration

Layer / File(s) Summary
App foundation: package, props, auth, and request core
components/stadium/package.json, components/stadium/stadium.app.mjs
Defines the npm package metadata, prop definitions (store number with dynamic listStores options, order number, country, pagination, payment method), OAuth client-credentials token acquisition, Bearer header construction, and the core _makeRequest axios wrapper.
Store catalog and user-profile actions
components/stadium/stadium.app.mjs, components/stadium/actions/get-user-profile/get-user-profile.mjs, components/stadium/actions/list-stores/list-stores.mjs, components/stadium/actions/get-store-products/get-store-products.mjs
Adds getUserProfile, listStores, and getStoreProducts app methods with pagination and filter query parameters, plus corresponding read-only action modules that export $summary strings with counts or email.
Transactional order actions: send-points, create-order, checkout-order
components/stadium/stadium.app.mjs, components/stadium/actions/send-points/send-points.mjs, components/stadium/actions/create-order/create-order.mjs, components/stadium/actions/checkout-order/checkout-order.mjs
Adds sendPoints, createOrder, and checkoutOrder app methods; corresponding action modules handle props including a JSON-parsed products field and paymentMethod as a query parameter.
Order query actions: get-order-details, get-shipment-status
components/stadium/stadium.app.mjs, components/stadium/actions/get-order-details/get-order-details.mjs, components/stadium/actions/get-shipment-status/get-shipment-status.mjs
Adds getOrderDetails and getShipmentStatus app methods and read-only actions that accept an orderNumber prop and return order or shipment data.
Automation order actions: create and check status
components/stadium/stadium.app.mjs, components/stadium/actions/create-automation-order/create-automation-order.mjs, components/stadium/actions/check-automation-order-status/check-automation-order-status.mjs
Adds createAutomationOrder and checkAutomationOrderStatus app methods that use an api_key header instead of Bearer auth; corresponding action modules accept a secret apiKey prop and optional payload fields.
README
components/stadium/README.md
Documents platform capabilities, plan requirements, token lifetime, example use cases, connection setup steps, and troubleshooting guidance for 401/422/404 errors.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Suggested reviewers

  • GTFalcao
🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The description provides a high-level overview but the checklist items critical for review are all unchecked, indicating incomplete preparation for merge. Check and complete all required checklist items: verify versioning updates, confirm app integration request submission, and address CodeRabbit review comments before resubmitting.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately summarizes the main change: introducing the Stadium app integration with a set of actions for various operations.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Actionable comments posted: 14

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In
`@components/stadium/actions/check-automation-order-status/check-automation-order-status.mjs`:
- Line 11: The openWorldHint property in the check-automation-order-status
action is currently set to false, but since this action calls Stadium's external
API, it must be set to true according to action annotation semantics. Change the
openWorldHint property value from false to true to properly indicate that this
action communicates with external APIs.

In
`@components/stadium/actions/create-automation-order/create-automation-order.mjs`:
- Around line 50-52: The conditional checks for recipientMessage, senderName,
and budget properties use truthiness evaluation, which incorrectly omits valid
falsy values like 0 or false. Remove the truthiness conditions and directly
assign these optional properties to the data object. The `@pipedream/platform`
axios will automatically strip only undefined values, allowing falsy values like
0 to be properly included in the payload.

In `@components/stadium/actions/create-order/create-order.mjs`:
- Around line 76-78: The JSON.parse call on this.products lacks validation and
will throw an unhelpful error if the JSON is invalid. Wrap the JSON.parse
statement in a try-catch block and throw a ConfigurationError with a clear,
actionable error message that tells users the products input is invalid JSON,
including details about what format is expected. This way invalid user input
will produce a pre-call configuration error instead of a low-context runtime
error.

In `@components/stadium/actions/get-order-details/get-order-details.mjs`:
- Around line 9-13: In the annotations object of the get-order-details.mjs file,
the openWorldHint property is currently set to false, but it must be set to true
because this action makes an external HTTP request. Locate the annotations
object containing destructiveHint, openWorldHint, and readOnlyHint properties,
and change the openWorldHint value from false to true to comply with the
requirement that all actions making external API calls must have openWorldHint
enabled.

In `@components/stadium/actions/get-shipment-status/get-shipment-status.mjs`:
- Around line 9-13: The openWorldHint property in the annotations object is
currently set to false, but it should be true since this action makes external
API calls. Locate the annotations object in the get-shipment-status.mjs file and
change the openWorldHint property value from false to true to comply with the
requirement that external API-calling actions must have openWorldHint set to
true.

In `@components/stadium/actions/get-store-products/get-store-products.mjs`:
- Around line 9-13: In the annotations object within the get-store-products.mjs
file, the openWorldHint property is currently set to false, but it must be set
to true because the action calls this.stadium.getStoreProducts() which makes an
external HTTP request to the Stadium API. Change the openWorldHint value from
false to true to properly signal that this action makes external API calls.

In `@components/stadium/actions/get-user-profile/get-user-profile.mjs`:
- Around line 9-13: The annotations object in get-user-profile.mjs has
openWorldHint set to false, but since this action calls
this.stadium.getUserProfile() which makes an external HTTP request to the
Stadium API, the openWorldHint property must be set to true according to the
path instructions. Change the openWorldHint property in the annotations object
from false to true to correctly signal that this action makes external API
calls.

In `@components/stadium/actions/list-stores/list-stores.mjs`:
- Around line 9-13: In the annotations object of the list-stores.mjs file,
change the openWorldHint property from false to true. This action makes an
external HTTP request through this.stadium.listStores(), so the openWorldHint
annotation must be set to true to correctly indicate to the platform that this
action makes external API calls.

In `@components/stadium/actions/send-points/send-points.mjs`:
- Around line 57-72: The paymentMethod prop is currently defined inline in
send-points.mjs but should use the shared propDefinition from the stadium app
file instead. Remove the inline paymentMethod prop definition (the entire object
with type, label, description, options, and optional fields) and replace it with
a single line using propDefinition: [stadium, "paymentMethod"], following the
same pattern already used in checkout-order.mjs. This ensures the prop
definition is centralized and prevents duplication and drift across multiple
actions.

In `@components/stadium/README.md`:
- Around line 42-44: The README documents a sandbox environment but the app
module has a hardcoded base URL in the `_baseUrl()` method that users cannot
override. Either add a configurable `apiUrl` prop to the app connection
component that allows users to set a custom API endpoint (defaulting to the
production URL if not provided), update the README to clarify that sandbox
testing requires custom deployment modifications, or remove the sandbox
environment section entirely if it is not supported in the current design.
Choose one approach and ensure consistency between the code capabilities and
documentation.
- Line 34: In the README.md file for the stadium component, the setup
instructions at line 34 use vague terminology "API credentials" when directing
users to contact engineering. Replace "API credentials" with the specific terms
"Client ID and Client Secret" to match the terminology referenced in line 39 and
provide clarity to users about exactly what credentials they should expect to
receive. Update the contact instruction text to explicitly mention these
credential types.

In `@components/stadium/stadium.app.mjs`:
- Around line 137-149: The _makeRequest method always injects OAuth headers via
this._headers(), but automation methods should use api_key-based authentication
instead. Add an optional parameter to the _makeRequest method destructuring
(such as a skipAuth or bypassAuth flag with a default value of false) and
conditionally include the OAuth headers from this._headers() only when this flag
is not set to true. Then update the automation methods mentioned at lines
297-307 and 317-327 to pass this flag as true when calling _makeRequest so they
bypass the Bearer auth injection and rely solely on api_key headers.
- Around line 297-299: The createAutomationOrder method is sourcing the apiKey
from method parameters instead of from this.$auth, which violates credential
handling policy. Remove the apiKey parameter from the method signature (remove
it from the destructured ...opts) and instead access the API key directly from
this.$auth within the method body wherever it is needed. Apply this same fix to
all other affected methods mentioned in the comment (around lines 317-319) that
similarly accept API credentials as parameters.
- Around line 3-6: The app export in the default object is missing the required
auth property definition, which causes this.$auth to be undefined at runtime.
The helper methods _clientId() and _clientSecret() located later in the file
attempt to read this.$auth.client_id and this.$auth.client_secret respectively,
but without the auth configuration declared in the app export, these values will
not be available. Add an auth object to the default export that specifies the
authentication type as client credentials and includes the required fields for
client_id and client_secret, ensuring the authentication configuration is
properly defined before any methods attempt to access this.$auth credentials.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 52f2d01b-0765-4b22-bea3-e16c80289934

📥 Commits

Reviewing files that changed from the base of the PR and between 1fef104 and ea0cd88.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (13)
  • components/stadium/README.md
  • components/stadium/actions/check-automation-order-status/check-automation-order-status.mjs
  • components/stadium/actions/checkout-order/checkout-order.mjs
  • components/stadium/actions/create-automation-order/create-automation-order.mjs
  • components/stadium/actions/create-order/create-order.mjs
  • components/stadium/actions/get-order-details/get-order-details.mjs
  • components/stadium/actions/get-shipment-status/get-shipment-status.mjs
  • components/stadium/actions/get-store-products/get-store-products.mjs
  • components/stadium/actions/get-user-profile/get-user-profile.mjs
  • components/stadium/actions/list-stores/list-stores.mjs
  • components/stadium/actions/send-points/send-points.mjs
  • components/stadium/package.json
  • components/stadium/stadium.app.mjs

Comment on lines +50 to +52
if (this.recipientMessage) data.recipient_message = this.recipientMessage;
if (this.senderName) data.sender_name = this.senderName;
if (this.budget) data.budget = this.budget;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Avoid truthiness-gating optional payload fields.

These checks silently omit valid falsy inputs (e.g., budget: 0). For actions, optional props can be passed directly and @pipedream/platform axios will strip only undefined.

Suggested fix
   async run({ $ }) {
     const data = {
       contact_emails: this.contactEmails,
+      recipient_message: this.recipientMessage,
+      sender_name: this.senderName,
+      budget: this.budget,
     };
-    if (this.recipientMessage) data.recipient_message = this.recipientMessage;
-    if (this.senderName) data.sender_name = this.senderName;
-    if (this.budget) data.budget = this.budget;
 
     const response = await this.stadium.createAutomationOrder({
       $,
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@components/stadium/actions/create-automation-order/create-automation-order.mjs`
around lines 50 - 52, The conditional checks for recipientMessage, senderName,
and budget properties use truthiness evaluation, which incorrectly omits valid
falsy values like 0 or false. Remove the truthiness conditions and directly
assign these optional properties to the data object. The `@pipedream/platform`
axios will automatically strip only undefined values, allowing falsy values like
0 to be properly included in the payload.

Sources: Coding guidelines, Path instructions

Comment thread components/stadium/actions/create-order/create-order.mjs Outdated
Comment thread components/stadium/actions/get-order-details/get-order-details.mjs
1. Sign up for a free Stadium account at [bystadium.com](https://www.bystadium.com/).
2. Create a Stadium Shop and curate your product catalog.
3. Set up your funding source (wallet funds for order payments).
4. Contact [engineering@bystadium.com](mailto:engineering@bystadium.com) to receive API credentials.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Clarify what "API credentials" means in the setup instructions.

Line 34 directs users to contact engineering to "receive API credentials," but does not specify that these are the Client ID and Client Secret referenced in line 39. Users may be uncertain whether they have the right credentials when they receive them.

Revise to: "Contact engineering@bystadium.com to receive your Client ID and Client Secret."

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/stadium/README.md` at line 34, In the README.md file for the
stadium component, the setup instructions at line 34 use vague terminology "API
credentials" when directing users to contact engineering. Replace "API
credentials" with the specific terms "Client ID and Client Secret" to match the
terminology referenced in line 39 and provide clarity to users about exactly
what credentials they should expect to receive. Update the contact instruction
text to explicitly mention these credential types.

Comment on lines +42 to +44
## Sandbox Environment

For testing, Stadium provides a sandbox environment at `https://api.preprod.bystadium.com`. Contact [engineering@bystadium.com](mailto:engineering@bystadium.com) for sandbox credentials.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Sandbox environment setup is incomplete: no guidance on switching the API endpoint.

The README mentions a sandbox environment at https://api.preprod.bystadium.com, but the app module has a hardcoded base URL (https://api.bystadium.com/api/v2 from the _baseUrl() method) with no configuration option visible to users. Users who obtain sandbox credentials will not know how to point their requests to the sandbox endpoint.

Either:

  • Add a configurable apiUrl prop to the app connection so users can override the base URL, or
  • Clarify in the README that sandbox testing requires a custom deployment, or
  • Remove the sandbox section if it is not practical within the current app design.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/stadium/README.md` around lines 42 - 44, The README documents a
sandbox environment but the app module has a hardcoded base URL in the
`_baseUrl()` method that users cannot override. Either add a configurable
`apiUrl` prop to the app connection component that allows users to set a custom
API endpoint (defaulting to the production URL if not provided), update the
README to clarify that sandbox testing requires custom deployment modifications,
or remove the sandbox environment section entirely if it is not supported in the
current design. Choose one approach and ensure consistency between the code
capabilities and documentation.

Comment on lines +3 to +6
export default {
type: "app",
app: "stadium",
propDefinitions: {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🩺 Stability & Availability | 🔴 Critical

🧩 Analysis chain

🏁 Script executed:

cat -n components/stadium/stadium.app.mjs | head -100

Repository: PipedreamHQ/pipedream

Length of output: 3306


🏁 Script executed:

cat -n components/stadium/stadium.app.mjs | tail -50

Repository: PipedreamHQ/pipedream

Length of output: 1801


🏁 Script executed:

grep -n "auth:" components/stadium/stadium.app.mjs

Repository: PipedreamHQ/pipedream

Length of output: 159


🏁 Script executed:

wc -l components/stadium/stadium.app.mjs && sed -n '1,70p' components/stadium/stadium.app.mjs

Repository: PipedreamHQ/pipedream

Length of output: 1859


🏁 Script executed:

find components/stadium -name "*.mjs" -type f

Repository: PipedreamHQ/pipedream

Length of output: 864


🏁 Script executed:

ast-grep outline components/stadium/stadium.app.mjs

Repository: PipedreamHQ/pipedream

Length of output: 208


🏁 Script executed:

sed -n '1,330p' components/stadium/stadium.app.mjs | grep -E "^\s*(auth|type|app|propDefinitions|methods)\s*:"

Repository: PipedreamHQ/pipedream

Length of output: 360


🏁 Script executed:

sed -n '3,330p' components/stadium/stadium.app.mjs | head -3 && echo "..." && sed -n '325,330p' components/stadium/stadium.app.mjs

Repository: PipedreamHQ/pipedream

Length of output: 266


🏁 Script executed:

sed -n '3,65p' components/stadium/stadium.app.mjs

Repository: PipedreamHQ/pipedream

Length of output: 1692


Define app auth configuration before reading this.$auth credentials.

Lines 76–87 contain helper methods _clientId() and _clientSecret() that read this.$auth.client_id and this.$auth.client_secret, but this app export does not declare an auth property. Without defining authentication credentials in the app configuration, this.$auth will be empty at runtime, causing all authenticated API calls to fail.

Add an auth object to the app export with the client credentials authentication type and required fields.

Also applies to: 76-87

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/stadium/stadium.app.mjs` around lines 3 - 6, The app export in the
default object is missing the required auth property definition, which causes
this.$auth to be undefined at runtime. The helper methods _clientId() and
_clientSecret() located later in the file attempt to read this.$auth.client_id
and this.$auth.client_secret respectively, but without the auth configuration
declared in the app export, these values will not be available. Add an auth
object to the default export that specifies the authentication type as client
credentials and includes the required fields for client_id and client_secret,
ensuring the authentication configuration is properly defined before any methods
attempt to access this.$auth credentials.

Comment thread components/stadium/stadium.app.mjs
Comment on lines +297 to +299
async createAutomationOrder({
apiKey, ...opts
}) {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift

Do not source API credentials from method parameters.

Passing apiKey into app methods implies the secret comes from action props instead of the app auth connection. This weakens credential handling consistency and violates the repo credential policy.

As per coding guidelines, "$auth is the only way components should access credentials. Auth tokens must never be hardcoded or sourced from other props." As per path instructions, "Runtime primitives: credentials must come from this.$auth (never hardcoded or taken from user props)."

Also applies to: 317-319

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/stadium/stadium.app.mjs` around lines 297 - 299, The
createAutomationOrder method is sourcing the apiKey from method parameters
instead of from this.$auth, which violates credential handling policy. Remove
the apiKey parameter from the method signature (remove it from the destructured
...opts) and instead access the API key directly from this.$auth within the
method body wherever it is needed. Apply this same fix to all other affected
methods mentioned in the comment (around lines 317-319) that similarly accept
API credentials as parameters.

Sources: Coding guidelines, Path instructions

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

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

apiKey is a part of action prop.

@michelle0927

Copy link
Copy Markdown
Collaborator

@Garvshah01 Thank you for your contribution! Would you mind submitting an app integration request for Stadium? Once we have a base integration in place, we can review and test this PR. Thanks!

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

♻️ Duplicate comments (1)
components/stadium/actions/send-points/send-points.mjs (1)

59-69: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win

Use shared paymentMethod propDefinition instead of inline options.

Line 59–69 still duplicates a prop that is used in multiple actions, which risks drift (already visible across this app). Reference the app-level shared definition instead of redefining labels/options here.

Suggested fix
-    paymentMethod: {
-      type: "string[]",
-      label: "Payment Methods",
-      description: "Payment method(s) to use. Pass one or both: `use_global_point`, `use_wallet_money`",
-      options: [
-        {
-          label: "Use Global Points",
-          value: "use_global_point",
-        },
-        {
-          label: "Use Wallet Money",
-          value: "use_wallet_money",
-        },
-      ],
-      optional: true,
-    },
+    paymentMethod: {
+      propDefinition: [
+        stadium,
+        "paymentMethod",
+      ],
+      optional: true,
+    },

As per coding guidelines, “Any prop used by more than one component must be defined in the app file's propDefinitions and referenced via propDefinition.” As per path instructions, “Props used in more than one component must be defined in the app file's propDefinitions and referenced via propDefinition.”

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@components/stadium/actions/send-points/send-points.mjs` around lines 59 - 69,
The "Payment Methods" prop definition with the options for "use_global_point"
and "use_wallet_money" is duplicated inline instead of referencing a shared
app-level propDefinition. Replace the entire inline prop definition (the object
containing label, description, and options array) with a reference to the shared
paymentMethod propDefinition from the app's propDefinitions section. This
follows the coding guideline that props used in multiple components must be
defined at the app level and referenced via propDefinition to prevent drift.

Sources: Coding guidelines, Path instructions

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Duplicate comments:
In `@components/stadium/actions/send-points/send-points.mjs`:
- Around line 59-69: The "Payment Methods" prop definition with the options for
"use_global_point" and "use_wallet_money" is duplicated inline instead of
referencing a shared app-level propDefinition. Replace the entire inline prop
definition (the object containing label, description, and options array) with a
reference to the shared paymentMethod propDefinition from the app's
propDefinitions section. This follows the coding guideline that props used in
multiple components must be defined at the app level and referenced via
propDefinition to prevent drift.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 77a3d68c-c373-40bf-a871-448502e99c31

📥 Commits

Reviewing files that changed from the base of the PR and between ea0cd88 and 25d2b32.

📒 Files selected for processing (10)
  • components/stadium/actions/check-automation-order-status/check-automation-order-status.mjs
  • components/stadium/actions/checkout-order/checkout-order.mjs
  • components/stadium/actions/create-order/create-order.mjs
  • components/stadium/actions/get-order-details/get-order-details.mjs
  • components/stadium/actions/get-shipment-status/get-shipment-status.mjs
  • components/stadium/actions/get-store-products/get-store-products.mjs
  • components/stadium/actions/get-user-profile/get-user-profile.mjs
  • components/stadium/actions/list-stores/list-stores.mjs
  • components/stadium/actions/send-points/send-points.mjs
  • components/stadium/stadium.app.mjs
💤 Files with no reviewable changes (1)
  • components/stadium/stadium.app.mjs

@michelle0927 michelle0927 added the blocked Issue is blocked pending a resolution label Jun 29, 2026
@michelle0927

Copy link
Copy Markdown
Collaborator

Moving to blocked while awaiting Stadium integration.

@michelle0927 michelle0927 moved this from Ready for PR Review to Blocked in Component (Source and Action) Backlog Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

blocked Issue is blocked pending a resolution User submitted Submitted by a user

Development

Successfully merging this pull request may close these issues.

5 participants