release: promote test to main#501
Conversation
* chore: update Prettier configuration and add new dependencies
- Added "endOfLine": "lf" to the Prettier configuration for consistent line endings.
- Introduced "stripe" and "uuid" packages in package.json for enhanced functionality.
- Updated pnpm-lock.yaml to reflect the addition of new dependencies.
* refactor(stripe): rename mapToSubscriptionSessionErrorResponse to mapToSubscriptionSessionError
- Updated the function name from `mapToSubscriptionSessionErrorResponse` to `mapToSubscriptionSessionError` for consistency and clarity.
- Adjusted import statements and references in related files to reflect the new function name.
* fix(tests): update ACCOUNT UUID in route.test.ts for consistency
- Changed the ACCOUNT constant in route.test.ts from "123e4567-e89b-12d3-a456-426614174000" to "123e4567-e89b-12d3-a456-426614174001" to ensure consistency in test cases.
* feat(stripe): add STRIPE_SK environment variable and improve error handling
- Introduced the STRIPE_SK environment variable in .env.example to ensure proper configuration for Stripe integration.
- Updated the Stripe client initialization to throw an error if STRIPE_SK is not set, enhancing robustness.
- Modified error handling in createSubscriptionSessionHandler to return a 500 status with a generic error message for internal server errors.
- Adjusted validation logic in validateCreateSubscriptionSessionRequest to remove the optional accountId field, simplifying the request structure.
- Enhanced mapToSubscriptionSessionError to mask upstream error messages for 5xx responses, improving security.
- Updated tests to reflect changes in error handling and validation logic.
* fix(connectors): unify action catalog and execution paths for consistent access
- Merged shared and artist toolkits into the actions catalog to ensure all executable actions are listed, reflecting the full access available to the chat agent.
- Updated the executeConnectorAction function to also utilize the merged toolkit, ensuring that all actions listed in the catalog are executable.
- Extracted ConnectorActionNotFoundError into a separate file for cleaner error handling and improved test organization.
- Rewritten tests to mock the new toolkit structure, ensuring comprehensive coverage of the updated functionality.
* feat(stripe): refactor createStripeSession to use configuration constants
- Updated createStripeSession to utilize STRIPE_SUBSCRIPTION_PRICE_ID and STRIPE_SUBSCRIPTION_TRIAL_PERIOD_DAYS constants for better maintainability and configuration management.
- Enhanced tests for createStripeSession to reflect these changes, ensuring consistency in the subscription parameters.
- Improved error handling in client tests by refining the management of the STRIPE_SK environment variable.
* chore: remove .gitattributes and update Prettier configuration
- Deleted the .gitattributes file to simplify project configuration.
- Updated .prettierrc by removing the "endOfLine" setting for cleaner formatting consistency.
* chore(stripe): drop uuid dep, use accountId as client_reference_id
YAGNI: client_reference_id is a soft-convenience pointer string with no
readers in either api or chat — never round-trips, never queried via the
sessions.list API (it isn't a filterable param). The migration was
generating a throwaway random uuid that mapped to nothing internally.
Setting it to accountId instead:
- removes the uuid dep entirely (only callsite in this repo)
- makes the Stripe dashboard's "Client reference" column actually
useful for support/debugging
- matches metadata.accountId so reconciliation is consistent
Drop the uuid mock from createStripeSession.test.ts and flip the
not.toBe("acc-1") assertion to toBe("acc-1") — encoding the new
contract instead of the old "value must be a random UUID" stance.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Sweets Sweetman <sweetmantech@gmail.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(api): migrate misc-reads endpoints (email, ai/models, youtube/channel-info)
Adds api parity for chat's /api/email, /api/ai/models, /api/youtube/channel-info
ahead of the chat-side cutover.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(api): address AI review on misc-reads PR
- updateContact: switch to loops v6 object-arg signature (fixes Vercel build)
- handlers: stop leaking raw exception text in 500 responses
- loopsClient: convert singleton to factory function matching filename
- youtubeErrors: align export name with filename
- getYouTubeChannelHandler: explicit boolean discriminator narrowing for build
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(api): change /api/email from GET to POST
Email tracking upserts a Loops contact — a write — so it should not be
exposed as GET with email in query params (PII in URLs, cacheable
responses). Switches to POST with `{ email }` JSON body.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* revert(api): drop /api/email endpoint
Loops is no longer used; the email tracking endpoint is removed
from this migration entirely.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): simplify youtube channel-info flow
- Fold token validation into validateYouTubeChannelInfoRequest so the
handler is a thin fetch+respond orchestrator
- Rename validateYouTubeChannelQuery → validateYouTubeChannelInfoRequest
(matches validateArtistRequest / validateChatRequest convention)
- Drop buildYouTubeUtilityError + error code catalog: every token-level
failure collapses to the same {success:false, tokenStatus:"invalid"}
response, so the typed codes carried no information out
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): throw from youtube libs, single catch at validator
- refreshStoredYouTubeToken now throws on every failure (no more
catch-log-return-null); the deep invalid_grant type guard is gone
since the general console.error already logs the full error
- validateYouTubeTokens lets errors propagate; null is reserved for
the legitimate "no tokens row / no refresh_token" cases
- validateYouTubeChannelInfoRequest is the single catch boundary;
thrown errors and null both collapse to the same tokenStatus:invalid
response, matching chat parity
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): drop redundant explicit return types from misc-reads libs
TS inference already produces the same types for these helpers; explicit
annotations were noise. Kept annotations on discriminated-union returns
(validators, route handlers) and anywhere inference would widen.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): drop more redundant return types from misc-reads libs
Continues 7f64027 — TS inference produces the same types for these
helpers; explicit annotations were noise. Kept the discriminated-union
annotation on validateYouTubeChannelInfoRequest where it documents an
intentional contract.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): slim youtube channel-info response and validator
- drop response fields that no chat consumer reads
- validateYouTubeTokens throws on every unusable case; the request
validator's catch is the single failure boundary (no more let/null)
- drop now-unnecessary explicit return types
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): trim youtube tests, jsdocs, type duplication, response
- Drop `success` from /api/youtube/channel-info; conform to the
`{ status: "success", channels }` envelope used across the rest of
the api (lib/networking/successResponse.ts, songs, posts, accounts,
chats, artists). Clients infer "needs re-auth" from
`channels === null`.
- Keep only validator + handler tests; cover no-token, expired-no-refresh,
refresh-failure, and db-update-failure cases at the validator boundary
via it.each on the thrown-error contract.
- Trim jsdocs to information-bearing lines only; drop stale
"mirrors chat" notes and self-evident @param/@returns lines on lib
helpers.
- Dedupe YouTubeTokensRow: keep the export in validateYouTubeTokens.ts
(the contract owner) and import it in refreshStoredYouTubeToken.ts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(api): return proper status codes for youtube channel-info errors
- 401 + {status:"error",message} when stored YouTube tokens can't be
validated/refreshed (re-auth needed)
- 502 + {status:"error",message} for upstream YouTube API failures
- Drops the inconsistent "200 status:success channels:null" shape
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): drop YouTubeTokensRow alias and return type
validateYouTubeTokens lets TS infer the return type; the alias is gone
(only refreshStoredYouTubeToken used it, now inlined as Tables<>).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(api): bypass @ai-sdk/gateway SDK for model catalog
The SDK's getAvailableModels() rejects valid responses with a Zod error
("expected error.object"), which silenced 194 models behind an empty
array. Match chat's direct fetch to /v1/ai/config — same approach,
same payload, same parity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(api): pin @ai-sdk/gateway to 2.x for catalog reads
The 3.x SDK requires specificationVersion:"v3" via a strict Zod literal,
but the live /v1/ai/config endpoint still emits "v2" descriptors. Pin
to 2.0.83 (latest 2.x, expects "v2") so gateway.getAvailableModels()
works as designed. This is a catalog-read-only consumer; api never uses
gateway() as a model factory, so 2.x's LanguageModelV2 surface doesn't
collide with the rest of the codebase on @ai-sdk/provider@3.
Restore the SDK call site (no more direct fetch hack); a comment
flags when to bump back to 3.x.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): drop redundant jsdoc on getAvailableModels
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* refactor(api): restore original jsdoc on getAvailableModels
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(api): gate /api/youtube/channel-info behind auth + artist access
Layers in validateAuthContext + checkAccountArtistAccess so anonymous
callers can no longer probe stored YouTube tokens by guessing UUIDs.
Returns 401 on missing/invalid auth, 403 when the authed caller has no
access to the requested artist.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* revert(api): drop /api/youtube/channel-info from this migration
YouTube channel-info will migrate via Composio in a separate PR.
Reduces Group 1 scope to just /api/ai/models.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Sweets Sweetman <sweetmantech@gmail.com>
* feat(api): migrate YouTube connector to Composio
- Add youtube to ALLOWED_ARTIST_CONNECTORS, ENABLED_TOOLKITS, SUPPORTED_TOOLKITS
- Plumb COMPOSIO_YOUTUBE_AUTH_CONFIG_ID through buildAuthConfigs
- Replace four custom MCP tools (login, channels, playlist videos,
thumbnail) with Composio's YouTube toolkit equivalents
(YOUTUBE_GET_CHANNEL_STATISTICS, YOUTUBE_LIST_PLAYLIST_ITEMS,
YOUTUBE_UPDATE_THUMBNAIL)
- Keep get_youtube_revenue MCP tool because Composio has no YouTube
Analytics action; rewrite it to fetch OAuth token from Composio's
connected_account state instead of the youtube_tokens table
* fix(api): pass artistId through executeConnectorAction so artist-scoped tools resolve
The validator collapsed the authenticated accountId and the optional
account_id override into a single field, so executeConnectorAction
called getComposioTools(accountId) with the artist account in
accountId and no artistId. getComposioTools then ran the customer
session pass against the artist (where the meta-only filter applies)
and got empty artistTools, so real tools like
YOUTUBE_GET_CHANNEL_STATISTICS were silently dropped — surfacing as
"Connector action not found" on the client.
Keep the two accountIds separate end-to-end: validator returns
{accountId (auth), artistId (target)}; handler forwards both;
executeConnectorAction calls getComposioTools(accountId, artistId).
The artist's connections now go through the artist owner scope where
non-meta tools survive — same path the LLM tool router uses, so
multi-tenant artist scoping is correct (different artists can have
different connected accounts).
* fix(api): unwrap Composio ToolExecuteResponse envelope so callers get the provider payload
`composio.tools.execute` (and the Vercel provider's `tool.execute`)
returns `{ successful, data, error, log_id }` — the actual provider
payload (e.g. Google channels.list response with `items`) lives at
`.data`, not at the top level. Callers like the chat YouTube hook were
reading `.items` off the envelope and getting `undefined`, rendering a
blank channel card despite a successful API call.
Unwrap on the api side so all `/api/connectors/actions` callers get the
underlying response directly — matches the OpenAPI doc claim that
"`result` passes through whatever the underlying connector returns".
Surface upstream failures (`successful: false`) as exceptions so they
turn into proper 500s instead of returning a misleading envelope.
Pass-through fallback preserves any provider that doesn't use the
envelope.
* fix(api): pass artistId through getConnectorActions for artist-scoped catalog
Same root cause as the executeConnectorAction fix: the validator was
collapsing the authenticated accountId and the optional account_id
override into a single field, so getConnectorActions(accountId) called
getComposioTools(accountId) without an artistId. The customer pass
then ran against the artist (where the meta-only filter applies),
returning zero artist-toolkit actions even though the connection was
active. Diagnostic against preview confirmed: GET /api/connectors
reported youtube isConnected: true while GET /api/connectors/actions
returned 0 youtube actions for the same artist.
Wire {accountId, artistId} end-to-end so the artist owner scope
resolves real tools (e.g. YOUTUBE_GET_CHANNEL_STATISTICS).
* chore(api): add temporary GET /api/debug/composio-youtube probe
Diagnostic-only — returns the per-step output of how Composio resolves
the artist's YouTube connection (getConnectors, connectedAccounts.list
filtered by userId, tools.get with and without authConfigs) so we can
see where YOUTUBE_GET_CHANNEL_STATISTICS is being dropped before
fetchOwnerTools surfaces it. Will be removed once the missing-actions
issue is fixed.
* fix(api): artist wins over customer in resolveSessionToolkits
Diagnostic against the deployed preview revealed the real reason
YouTube actions never made it into the artist-scoped catalog: the
api-key holder (customer) ALSO had YouTube connected on their own
account, so resolveSessionToolkits excluded `youtube` from
resolved.artist (per the old `!customerConnectedSlugs.has(slug)`
filter). It then ended up only in resolved.customer, where the
customer pass meta-only filter at the merge step in getComposioTools
silently dropped every YOUTUBE_* tool. Net effect: artist's
connection invisible to the chat agent and the connector-actions
catalog whenever the customer also had the same toolkit connected.
Flip the priority to artist > customer > shared in artist context.
The chat agent is acting on behalf of the artist; routing overlapping
toolkits to customer was always the wrong call because customer's
non-meta tools never survive the merge anyway. Customer's session
still loads every enabled toolkit so meta-tools (manage_connections
etc.) keep working — only the per-toolkit ownership for non-meta
tools changes.
Tests updated to encode the new semantics; removed the temporary
debug endpoint that was used to trace this.
* refactor(api): scope Composio Tool Router session to the artist, not the customer
Every chat in this codebase is artist-scoped, so running the Tool
Router session against the authenticated customer (and then trying to
keep the customer/artist toolkit ownership untangled) was the wrong
shape. It also caused the in-chat connect prompt
(COMPOSIO_MANAGE_CONNECTIONS) to register OAuth connections under the
customer accountId instead of the artist's — exactly what we hit when
the customer ended up with a stray ca_cHOgkKQlHMqL youtube connection
after going through the in-chat flow.
Single artist-scoped session now: meta-tools come from
composio.create(artistId, …) so manage_connections operates on the
artist. Real artist tools still go through composio.tools.get(artistId,
…) (Composio rejects cross-account connectedAccount overrides at
execute time). Shared platform tools unchanged.
Drops resolveSessionToolkits — the customer-vs-artist priority logic
it encoded no longer applies. If artistId is missing (not currently
possible for chat) or access check fails, no Composio tools are
returned. Reverts the artist > customer priority workaround pushed
earlier in this branch — the original priority-by-exclusion was
correct given the (now-true) assumption that customer-level toolkit
connections shouldn't exist for artist-scoped chats.
* Revert "refactor(api): scope Composio Tool Router session to the artist, not the customer"
This reverts commit f2e2640.
* fix(api): scope manage_connections to artist when chat has artist context
The customer Tool Router session had `manageConnections: { callbackUrl }`,
which made the LLM-triggered COMPOSIO_MANAGE_CONNECTIONS meta-tool
initiate OAuth under the *customer's* accountId — so any "connect
YouTube via chat" prompt registered the connection on the customer
instead of the artist. Result: stray ca_* customer connections
accumulated for artist-only toolkits (tiktok/instagram/youtube), and
chat agent couldn't see the artist's actual connection because of the
overlap with customer's orphan.
One-line change: when `effectiveArtistId` is set, create the Tool
Router session against the artist instead of the customer. Meta tools
are identical regardless of owner, so the merge filter that keeps
only meta tools from this session is unaffected. Pairs with the
earlier resolver flip (artist wins on toolkit overlap) so any
existing customer-level orphans become harmless rather than
shadowing the artist's connection.
* Revert "fix(api): scope manage_connections to artist when chat has artist context"
This reverts commit ba0cc7b.
* Revert "fix(api): pass artistId through getConnectorActions for artist-scoped catalog"
This reverts commit 4747dfe.
* Revert "fix(api): artist wins over customer in resolveSessionToolkits"
This reverts commit efe1d8d.
* refactor(api): bypass tool router merge in executeConnectorAction
For a single-account REST execution we don't need the customer/artist/
shared merge from `getComposioTools` (and going through it forces
artistId-as-second-arg plumbing through validator + handler + tests).
Call `composio.tools.get(accountId, ...)` directly with the same
ENABLED_TOOLKITS. Composio returns tools owned by that account, which
is what the chat hook (sending account_id: artistId) actually needs.
Drops the artistId parameter from executeConnectorAction's signature
and reverts the validator/handler back to the original collapsed
{accountId, actionSlug, parameters} shape.
Also trims verbose JSDocs on the YouTube migration files.
* fix(api): customer pass keeps real tools when no artistId in scope
The customer-pass meta-only filter in getComposioTools was the right
behavior for the LLM tool router (where artist/shared provide real
tools and customer must not duplicate them) — but wrong for the
single-account REST execute path, where there is no artist pass and
the customer pass IS the source of real tools. Make the filter
conditional on `effectiveArtistId`: keep meta-only when artist is in
scope, keep everything when it's not.
executeConnectorAction goes back to calling getComposioTools(accountId)
— no signature change, no validator/handler plumbing. The single-arg
path now actually works.
* revert: leave executeConnectorAction unchanged from main
The envelope unwrap belongs on the consumer side. The api stays a thin
pass-through of Composio's ToolExecuteResponse.
* refactor(api): merge owner tool sets by spread priority, drop resolveSessionToolkits
Each owner (customer, artist, shared) is fetched independently for the
toolkits it has connected — no exclusion-based dedup. Spread order in
the merge resolves collisions: shared (lowest) → customer → artist
(highest, when in scope). Same priority outcome as before for the LLM
agent, but customer's own real tools now surface too — which is what
makes single-account REST execution (executeConnectorAction with no
artistId) actually return real tools instead of just meta.
resolveSessionToolkits was the previous exclusion-based dedup; with
spread-priority it's redundant and unused.
* refactor(api): drop redundant effectiveArtistId guard on artistToolkits filter
* refactor(api): rename getTools.ts → getComposioTools.ts; restore original variable names
Filename now matches the exported function (project convention).
Variable names back to customerRaw/customerTools/artistTools/sharedTools
— no gratuitous renames.
* fix(api): authenticate get_youtube_revenue MCP tool
The tool blindly trusted the artist_account_id passed in args — anyone
with a valid api key could pull any artist's revenue by knowing its
UUID. Resolve the account through resolveAccountId so the bearer
token / api key holder is verified to have access to the artist
(canAccessAccount check) before any Composio or analytics call runs.
Matches the project convention from api/CLAUDE.md: "Never use
account_id in request bodies or tool schemas. Always derive the
account ID from authentication."
* refactor(api): simplify getConnectedAccountAccessToken state access
* fix(api): use checkAccountArtistAccess for revenue tool auth
resolveAccountId calls canAccessAccount which only validates org-based
access — it misses direct artist ownership via account_artist_ids,
so an api-key holder accessing their own owned artist gets rejected.
Switch to checkAccountArtistAccess directly. Same function the REST
artist-scoped endpoints already use; covers direct ownership +
RECOUP_ORG admin + shared-org paths.
* fix(api): query YouTube Analytics through composio.tools.proxy
Composio masks access_token / refresh_token in connectedAccounts.get
responses by default — the literal "REDACTED" was being passed to
googleapis, which surfaced as `invalid_grant` from Google. Switching
to composio.tools.proxy means the token never leaves Composio: they
inject auth and refresh transparently for every proxied HTTP call.
Drops getConnectedAccountAccessToken, oauth-client.ts,
createYouTubeAnalyticsClient.ts, and the entire googleapis package
from this codebase.
* fix(api): use composio.tools.proxyExecute (correct @composio/core method name)
The @composio/core SDK exposes proxyExecute (not proxy — that's the
lower-level @composio/client method name). Param key is also camelCase
connectedAccountId, not snake_case.
* chore: nudge Vercel preview redeploy
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Caution Review failedPull request was closed or merged during review 📝 WalkthroughWalkthroughThis PR migrates YouTube integration from a legacy token-based system to Composio connectors. It adds YouTube to supported toolkits and artist connectors, refactors the tool router to resolve toolkits explicitly by connection scope, removes legacy YouTube MCP tools and token management, and updates analytics to query via Composio's proxy instead of direct API calls. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 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. Review rate limit: 0/1 reviews remaining, refill in 60 minutes.Comment |
There was a problem hiding this comment.
1 issue found across 31 files
Confidence score: 4/5
- This PR looks safe to merge with minimal risk: the reported issue is maintainability-focused rather than a functional bug or regression.
- The main concern is in
lib/composio/toolRouter/getComposioTools.ts, which exceeds the 100-line style limit and may make future edits/reviews harder. - Given the low severity (4/10) and high confidence, this is best treated as cleanup follow-up rather than a merge blocker.
- Pay close attention to
lib/composio/toolRouter/getComposioTools.ts- reduce file size/split logic to improve readability and long-term maintainability.
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="lib/composio/toolRouter/getComposioTools.ts">
<violation number="1" location="lib/composio/toolRouter/getComposioTools.ts:58">
P2: Custom agent: **Enforce Clear Code Style and Maintainability Practices**
File exceeds the 100-line maximum required by the maintainability rule.</violation>
</file>
Architecture diagram
sequenceDiagram
participant Client as Client (UI/LLM)
participant API as API Route / MCP Server
participant TR as Tool Router
participant Composio as Composio Service
participant YT as YouTube Analytics API
participant Stripe as Stripe API
Note over Client, Stripe: NEW: Tool Discovery & Routing Flow
Client->>TR: getComposioTools(accountId, artistId)
TR->>TR: checkAccountArtistAccess()
par Parallel Fetch per Owner
TR->>Composio: fetchOwnerTools(SHARED_ACCOUNT_ID)
Composio-->>TR: Shared Tools (e.g., Google Docs)
and
TR->>Composio: fetchOwnerTools(accountId)
Composio-->>TR: Customer Tools
and
opt If artistId provided
TR->>Composio: fetchOwnerTools(artistId)
Composio-->>TR: Artist Tools (High Priority)
end
end
TR->>Composio: NEW: create(accountId) with ENABLED_TOOLKITS (incl. youtube)
Composio-->>TR: Tool Router Session (Meta-tools)
TR->>TR: CHANGED: Merge tools with priority<br/>(Shared < Customer < Artist)
TR-->>Client: Merged ToolSet
Note over Client, YT: NEW: YouTube Analytics Flow (via Proxy)
Client->>API: call get_youtube_revenue(artist_account_id)
API->>API: checkAccountArtistAccess()
API->>Composio: NEW: proxyExecute(GET /v3/channels)
Note right of Composio: Uses Auth Config ID & Connected Account
Composio->>YT: Request with managed OAuth token
YT-->>Composio: Channel ID
Composio-->>API: channelId
API->>Composio: NEW: proxyExecute(GET /v2/reports)
Composio->>YT: Analytics Query
YT-->>Composio: Revenue Data
Composio-->>API: rows (dailyRevenue)
API-->>Client: Aggregated Revenue Report
Note over Client, Stripe: CHANGED: Stripe Checkout Flow
Client->>API: POST /api/stripe/checkout
API->>Stripe: createSession()
Note right of API: CHANGED: client_reference_id = accountId
Stripe-->>API: sessionUrl
API-->>Client: 303 Redirect
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| @@ -4,7 +4,6 @@ import { getCallbackUrl } from "../getCallbackUrl"; | |||
| import { getConnectors } from "../connectors/getConnectors"; | |||
There was a problem hiding this comment.
P2: Custom agent: Enforce Clear Code Style and Maintainability Practices
File exceeds the 100-line maximum required by the maintainability rule.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At lib/composio/toolRouter/getComposioTools.ts, line 58:
<comment>File exceeds the 100-line maximum required by the maintainability rule.</comment>
<file context>
@@ -55,43 +55,51 @@ export async function getComposioTools(
- artistConnectedSlugs: toConnectedSlugs(artistConnectors),
- sharedConnectedSlugs: new Set(Object.keys(sharedConnections)),
- });
+ const customerConnectedSlugs = toConnectedSlugs(customerConnectors);
+ const artistConnectedSlugs = toConnectedSlugs(artistConnectors);
+ const sharedConnectedSlugs = new Set(Object.keys(sharedConnections));
</file context>
Promote
testtomain. Includes:🤖 Generated with Claude Code
Summary by cubic
Promotes test to main with a Composio-based YouTube connector, a simplified tool routing merge, secure YouTube Analytics via Composio proxy, Stripe checkout session improvements, and the GET /api/ai/models migration.
New Features
Refactors
googleapisdependency.Written for commit 3f430b3. Summary will update on new commits.
Summary by CodeRabbit
Release Notes
New Features
Refactor