Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Comment on lines
77
to
89
| const customerId = "temp"; | ||
|
|
||
| const pro = products.pro({ | ||
| id: "pro", | ||
| items: [items.monthlyMessages({ includedUsage: 500 })], | ||
| }); | ||
|
|
||
| const premium = products.premium({ | ||
| id: "premium", | ||
| items: [items.monthlyMessages({ includedUsage: 1000 })], | ||
| }); | ||
|
|
||
| const { autumnV1, testClockId, ctx } = await initScenario({ | ||
| customerId, | ||
| // customerId, | ||
| setup: [ | ||
| s.customer({ paymentMethod: "success" }), | ||
| s.products({ list: [pro, premium] }), | ||
| // s.customer({ paymentMethod: "success" }), | ||
| // s.products({ list: [pro, premium] }), | ||
| ], | ||
| actions: [], | ||
| }); | ||
|
|
||
| const stripeCli = createStripeCli({ org: ctx.org, env: ctx.env }); | ||
|
|
||
| const coupon = await createPercentCoupon({ | ||
| stripeCli, | ||
| percentOff: 20, | ||
| duration: "repeating", | ||
| durationInMonths: 1, | ||
| }); | ||
|
|
||
| await autumnV1.billing.attach({ | ||
| customer_id: customerId, | ||
| product_id: pro.id, | ||
| redirect_mode: "if_required", | ||
| discounts: [ | ||
| { | ||
| reward_id: coupon.id, | ||
| }, | ||
| ], | ||
| }); | ||
|
|
||
| await autumnV1.billing.attach({ | ||
| customer_id: customerId, | ||
| product_id: premium.id, | ||
| redirect_mode: "if_required", | ||
| }); | ||
|
|
||
| await autumnV1.billing.attach({ | ||
| customer_id: customerId, | ||
| product_id: pro.id, | ||
| redirect_mode: "if_required", | ||
| }); | ||
| await testStripeCustomerWithGBP({ ctx, autumn: autumnV1 }); | ||
| }); |
Contributor
There was a problem hiding this comment.
Work-in-progress test committed with commented-out setup
The initScenario call has customerId, s.customer, and s.products all commented out. This means the scenario initialises with no customer and no products, so the ctx object passed to testStripeCustomerWithGBP may lack a properly configured org/environment. Since the hardcoded Stripe product ID ("prod_U5XwDFBQB4TQJ7") also looks environment-specific, this test is likely to silently no-op or fail in other environments. Consider either fully enabling it (with proper fixtures) or keeping it out of the committed codebase until it's ready.
Prompt To Fix With AI
This is a comment left during a code review.
Path: server/tests/_temp/temp.test.ts
Line: 77-89
Comment:
**Work-in-progress test committed with commented-out setup**
The `initScenario` call has `customerId`, `s.customer`, and `s.products` all commented out. This means the scenario initialises with no customer and no products, so the `ctx` object passed to `testStripeCustomerWithGBP` may lack a properly configured org/environment. Since the hardcoded Stripe `product` ID (`"prod_U5XwDFBQB4TQJ7"`) also looks environment-specific, this test is likely to silently no-op or fail in other environments. Consider either fully enabling it (with proper fixtures) or keeping it out of the committed codebase until it's ready.
How can I resolve this? If you propose a fix, please make it concise.![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
1 issue found across 8 files
Confidence score: 4/5
- This PR is likely safe to merge, with only a small process risk rather than a runtime regression risk.
- The main issue is in
.opencode/plans/alb-lambda-logging-fix.md: the verification command uses macOS-onlydate -v, which can cause the documented CloudWatch check to fail on GNU/Linux. - Given the issue severity (4/10) and that it affects verification steps in documentation/planning, impact appears limited and non-blocking for production behavior.
- Pay close attention to
.opencode/plans/alb-lambda-logging-fix.md- update thedate -vcommand to a cross-platform/GNU-compatible form so validation works across environments.
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name=".opencode/plans/alb-lambda-logging-fix.md">
<violation number="1" location=".opencode/plans/alb-lambda-logging-fix.md:41">
P2: The CloudWatch command uses a macOS-specific `date -v` flag, so the verification steps fail on GNU/Linux environments.</violation>
</file>
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| --namespace AWS/Lambda \ | ||
| --metric-name Errors \ | ||
| --dimensions Name=FunctionName,Value=alb-listener-us-east-2 \ | ||
| --start-time $(date -u -v-24H +%Y-%m-%dT%H:%M:%SZ) \ |
Contributor
There was a problem hiding this comment.
P2: The CloudWatch command uses a macOS-specific date -v flag, so the verification steps fail on GNU/Linux environments.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At .opencode/plans/alb-lambda-logging-fix.md, line 41:
<comment>The CloudWatch command uses a macOS-specific `date -v` flag, so the verification steps fail on GNU/Linux environments.</comment>
<file context>
@@ -0,0 +1,89 @@
+ --namespace AWS/Lambda \
+ --metric-name Errors \
+ --dimensions Name=FunctionName,Value=alb-listener-us-east-2 \
+ --start-time $(date -u -v-24H +%Y-%m-%dT%H:%M:%SZ) \
+ --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ) \
+ --period 3600 \
</file context>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary by cubic
Fixes billing attach and subscription updates when a customer has a card attached but no default_payment_method in Stripe by passing a fallback payment method. Also uses the Stripe customer's currency for in‑arrear line items.
Bug Fixes
Tests
Written for commit 6cd83f7. Summary will update on new commits.
Greptile Summary
This PR fixes a billing edge case where a Stripe customer has a payment method attached but
invoice_settings.default_payment_methodis null (e.g. after being manually cleared), causing subscription create/update operations to fail because Stripe had no PM to charge. It also corrects currency resolution for arrear line items to honour the customer's locked Stripe currency rather than always defaulting to the org-level currency.Key changes:
executeStripeSubscriptionOperation.ts: wheninvoice_settings.default_payment_methodis null on the customer but a resolvedpaymentMethodexists inBillingContext, it is now passed explicitly asdefault_payment_methodon the subscriptioncreatecall, and on theupdatecall when the subscription itself also lacks a default PM.customerProductToArrearLineItems.ts: currency for arrear line items now prefersbillingContext.stripeCustomer.currencyover the org default, fixing incorrect currency usage for customers billed in a non-org currency (e.g. GBP).processConsumablePricesForInvoiceCreated.ts: removes an unused variable assignment fromcreateStripeInvoiceItems.attach-pm-edge-case.test.ts) covering the fixed scenario end-to-end..opencode/opencode.json: adds Axiom MCP server for log querying tooling;.opencode/plans/alb-lambda-logging-fix.mddocuments the ALB → Lambda → Axiom logging pipeline fix.Confidence Score: 4/5
temp.test.tsbeing committed in a half-finished state with commented-out setup and a hardcoded Stripe product ID, which could cause confusion or flaky test runs in other environments.Important Files Changed
default_payment_methodto subscription create/update when the Stripe customer'sinvoice_settings.default_payment_methodis null but a resolved payment method exists. Logic is sound — create always gets the fallback; update only gets it when neither the subscription nor the customer has a default PM already set.invoiceItemsvariable assignment fromcreateStripeInvoiceItemscall. No behavioural change.invoice_settings.default_payment_methodcan still successfully attach a product. Clears the field using"" as string(Stripe SDK convention for unsetting string fields).Sequence Diagram
sequenceDiagram participant Caller participant executeStripeSubscriptionOperation participant BillingContext participant StripeAPI Caller->>executeStripeSubscriptionOperation: call(ctx, billingContext, subscriptionAction) executeStripeSubscriptionOperation->>BillingContext: read paymentMethod executeStripeSubscriptionOperation->>BillingContext: read stripeCustomer.invoice_settings.default_payment_method Note over executeStripeSubscriptionOperation: customerHasDefaultPm = invoice_settings.default_payment_method alt paymentMethod exists AND customerHasDefaultPm is falsy executeStripeSubscriptionOperation->>executeStripeSubscriptionOperation: fallbackPaymentMethodParams = { default_payment_method: paymentMethod.id } else executeStripeSubscriptionOperation->>executeStripeSubscriptionOperation: fallbackPaymentMethodParams = {} end alt subscriptionAction.type == "create" executeStripeSubscriptionOperation->>StripeAPI: subscriptions.create({ ...params, ...fallbackPaymentMethodParams }) else subscriptionAction.type == "update" executeStripeSubscriptionOperation->>BillingContext: read stripeSubscription.default_payment_method Note over executeStripeSubscriptionOperation: subscriptionHasDefaultPm = subscription.default_payment_method alt subscriptionHasDefaultPm is falsy executeStripeSubscriptionOperation->>StripeAPI: subscriptions.update({ ...params, ...fallbackPaymentMethodParams }) else executeStripeSubscriptionOperation->>StripeAPI: subscriptions.update({ ...params }) end end StripeAPI-->>Caller: Stripe.SubscriptionLast reviewed commit: 6cd83f7