Add Stadium app integration with actions#21227
Conversation
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>
|
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:
|
📝 WalkthroughWalkthroughThis PR adds a complete new Pipedream integration for the Stadium platform. It introduces a core app module ( ChangesStadium Integration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
There was a problem hiding this comment.
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
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (13)
components/stadium/README.mdcomponents/stadium/actions/check-automation-order-status/check-automation-order-status.mjscomponents/stadium/actions/checkout-order/checkout-order.mjscomponents/stadium/actions/create-automation-order/create-automation-order.mjscomponents/stadium/actions/create-order/create-order.mjscomponents/stadium/actions/get-order-details/get-order-details.mjscomponents/stadium/actions/get-shipment-status/get-shipment-status.mjscomponents/stadium/actions/get-store-products/get-store-products.mjscomponents/stadium/actions/get-user-profile/get-user-profile.mjscomponents/stadium/actions/list-stores/list-stores.mjscomponents/stadium/actions/send-points/send-points.mjscomponents/stadium/package.jsoncomponents/stadium/stadium.app.mjs
| if (this.recipientMessage) data.recipient_message = this.recipientMessage; | ||
| if (this.senderName) data.sender_name = this.senderName; | ||
| if (this.budget) data.budget = this.budget; |
There was a problem hiding this comment.
🎯 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
| 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. |
There was a problem hiding this comment.
📐 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.
| ## 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. |
There was a problem hiding this comment.
📐 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
apiUrlprop 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.
| export default { | ||
| type: "app", | ||
| app: "stadium", | ||
| propDefinitions: { |
There was a problem hiding this comment.
🩺 Stability & Availability | 🔴 Critical
🧩 Analysis chain
🏁 Script executed:
cat -n components/stadium/stadium.app.mjs | head -100Repository: PipedreamHQ/pipedream
Length of output: 3306
🏁 Script executed:
cat -n components/stadium/stadium.app.mjs | tail -50Repository: PipedreamHQ/pipedream
Length of output: 1801
🏁 Script executed:
grep -n "auth:" components/stadium/stadium.app.mjsRepository: PipedreamHQ/pipedream
Length of output: 159
🏁 Script executed:
wc -l components/stadium/stadium.app.mjs && sed -n '1,70p' components/stadium/stadium.app.mjsRepository: PipedreamHQ/pipedream
Length of output: 1859
🏁 Script executed:
find components/stadium -name "*.mjs" -type fRepository: PipedreamHQ/pipedream
Length of output: 864
🏁 Script executed:
ast-grep outline components/stadium/stadium.app.mjsRepository: 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.mjsRepository: PipedreamHQ/pipedream
Length of output: 266
🏁 Script executed:
sed -n '3,65p' components/stadium/stadium.app.mjsRepository: 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.
| async createAutomationOrder({ | ||
| apiKey, ...opts | ||
| }) { |
There was a problem hiding this comment.
🔒 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
There was a problem hiding this comment.
apiKey is a part of action prop.
|
@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! |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
components/stadium/actions/send-points/send-points.mjs (1)
59-69: 📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick winUse shared
paymentMethodpropDefinitioninstead 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
propDefinitionsand referenced viapropDefinition.” As per path instructions, “Props used in more than one component must be defined in the app file'spropDefinitionsand referenced viapropDefinition.”🤖 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
📒 Files selected for processing (10)
components/stadium/actions/check-automation-order-status/check-automation-order-status.mjscomponents/stadium/actions/checkout-order/checkout-order.mjscomponents/stadium/actions/create-order/create-order.mjscomponents/stadium/actions/get-order-details/get-order-details.mjscomponents/stadium/actions/get-shipment-status/get-shipment-status.mjscomponents/stadium/actions/get-store-products/get-store-products.mjscomponents/stadium/actions/get-user-profile/get-user-profile.mjscomponents/stadium/actions/list-stores/list-stores.mjscomponents/stadium/actions/send-points/send-points.mjscomponents/stadium/stadium.app.mjs
💤 Files with no reviewable changes (1)
- components/stadium/stadium.app.mjs
|
Moving to blocked while awaiting Stadium integration. |
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
0.0.1for new ones)package.json's version updatedNew app
If this is a new app, please submit an app integration request - the PR will only be reviewed after the app is 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.
Summary by CodeRabbit
New Features
Documentation