Repository navigation
v0.9.46: exact hosted Fal.ai generation costs, Chat workflow tools answer with their resume link, Stripe checkout closed to AWS Marketplace customers - #9753
Conversation
waleedlatif1
commented
Nov 6, 2026
- fix(billing): settle hosted fal generations to their exact cost (fix(billing): settle hosted fal generations to their exact cost #9750)
- fix(mothership): answer a Chat workflow tool paused for a person with its resume link (fix(mothership): answer a Chat workflow tool paused for a person with its resume link #9751)
- fix(billing): refuse Stripe checkout for AWS Marketplace-billed customers (fix(billing): refuse Stripe checkout for AWS Marketplace-billed customers #9748)
…mers (#9748) * fix(billing): refuse Stripe checkout for AWS Marketplace-billed customers AWS bills a Marketplace customer, and AWS's SaaS guidelines require a listed product to be billed entirely through its Marketplace dimensions. A Marketplace-billed organization or account looks Free to Stripe, so a Stripe checkout would start a second, real subscription. Until now only a client gate stood in the way, and it failed open: a failed license lookup reported "not Marketplace-billed" and showed Stripe plans, with no retry short of a reload. Server: authorizeSubscriptionReference (organization references) and assertPersonalCheckoutAllowed (personal references) now refuse an upgrade with 409 when the reference holds a Marketplace license that is not inactive, only where AWS_MARKETPLACE_PRODUCT_CODE is set. The personal check lives in assertPersonalCheckoutAllowed because the Better Auth Stripe plugin never calls authorizeReference for a personal reference, so a check there would never run for one. Other actions, and staff Enterprise provisioning, are unaffected. Client: useAwsMarketplaceBilling exposes isResolved, isError, isRetrying and retry, and an unknown billing state now gates plan changes. The billing page hides "Explore plans" until the lookup resolves; the upgrade page shows "Workspace plans unavailable" with a "Try again" chip when the lookup fails. * fix(billing): keep the Marketplace lookup retry stable across renders
… its resume link (#9751) * fix(mothership): answer a Chat workflow tool paused for a person with its resume link A browser-run workflow tool whose run paused at a Human in the Loop block was never answered: the browser reports nothing for a paused run, the execute route's report skipped a non-terminal log, and the lapsed-wait watcher only detaches a running log. The Chat turn parked on the call until it timed out, and the model never learned the run was waiting on the user or where to answer. - Settle the call when its run waits on a person, with the resume page link and an instruction to hand it to the user rather than resume it. A run paused only on time resumes itself and keeps the call held. - The Chat-side waiter re-reads the pause and the call's binding instead of trusting a confirmation's data. - The lapsed-wait watcher answers a human pause if the route's report failed. - Share the pause point parser between run status reads and this check. * fix(mothership): answer a paused Chat workflow tool still running when its form was submitted before Chat read the pause
* fix(billing): settle hosted fal generations to their exact cost * fix(billing): settle into the payer's current period and cancel on trusted fal URLs * fix(billing): settle zero fal estimates and fix the settlement fixture payer
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
[High impact] The PR reaches hosted media billing, Chat workflow responses, and subscription checkout. The PR appears safe to merge, with a non-blocking mismatch between settled charges and the run costs shown in the logs list. Findings
SummaryAdds delayed Fal.ai billing settlement, returns resume links for Chat workflow tools waiting on a person, and blocks Stripe checkout for AWS Marketplace customers.
|
| await recordUsage({ | ||
| userId: attribution.actorUserId, | ||
| workspaceId: attribution.workspaceId ?? undefined, | ||
| workflowId: ledger.workflowId, | ||
| executionId: ledger.executionId, | ||
| billingEntity: { ...attribution.billingEntity }, | ||
| billingPeriod: { | ||
| start: new Date(attribution.billingPeriod.start), | ||
| end: new Date(attribution.billingPeriod.end), | ||
| }, | ||
| entries: [ | ||
| { | ||
| category: 'tool', | ||
| source: ledger.source, | ||
| description: `fal exact cost settlement: ${endpointId}`, | ||
| cost: shortfallDollars, | ||
| eventKey: stableEventKey({ kind: 'falai-cost-settlement', requestId }), |
There was a problem hiding this comment.
Run costs disagree after settlement
settleFalAICost adds the extra workflow charge to usageLog but never updates workflowExecutionLogs.costTotal. The logs list and cost filters keep using the original estimate, while opening the run shows the higher ledger total. Refresh the stored run total when a settlement charge is inserted, using the same protection against concurrent updates as the execution logger.