fix(snowflake): drop invalid session:role-any scope from OAuth flow

[AhmadTash]

What does this PR do?

Fixes the Snowflake OAuth connection flow, which was failing for every customer with The requested scope is invalid before they could even authenticate.

The piece was sending session:role-any refresh_token as the OAuth scope. Per Snowflake's custom OAuth docs, session:role-any is only valid for External OAuth integrations (where another IdP like Okta or Azure issues the token). For the custom client integration that the piece's setup SQL creates (OAUTH_CLIENT = CUSTOM), the only accepted scope values are refresh_token and session:role:<ROLE_NAME>. Snowflake therefore rejected the request at /oauth/authorize before the user was shown the sign-in screen.

This PR:

• Drops session:role-any from the requested OAuth scope, leaving refresh_token.
• Adds OAUTH_USE_SECONDARY_ROLES = IMPLICIT to the setup SQL so the Default Role field still works for switching to any role granted to the user after the token is issued.
• Bumps the piece version 0.3.1 → 0.3.2.

Explain How the Feature Works

After the change, the OAuth flow looks like this:

1. The user runs the updated CREATE SECURITY INTEGRATION SQL in Snowflake (now including OAUTH_USE_SECONDARY_ROLES = IMPLICIT).
2. The piece redirects the browser to https://<account>.snowflakecomputing.com/oauth/authorize?…&scope=refresh_token.
3. Snowflake accepts the scope, the user signs in, and the token is issued for the user's default Snowflake role.
4. When a query runs, snowflake.createConnection({ role }) switches the session to the role configured in the Default Role field. OAUTH_USE_SECONDARY_ROLES = IMPLICIT is what lets the token use any role granted to the user, so the Default Role field is no longer silently ignored.

Verified end-to-end against a fresh Snowflake trial account: the previous scope=session:role-any+refresh_token URL reproduces the customer's "The requested scope is invalid" error, and the patched scope=refresh_token URL passes through to the sign-in screen and issues a working token.

Relevant User Scenarios

• Any customer setting up a new Snowflake OAuth connection. The integration was effectively broken for new connections — the authorize step rejected the request before authentication, so no one could complete OAuth without falling back to the username/password or key-pair auth path.
• Customers who want to use a non-default Snowflake role at query time. The added OAUTH_USE_SECONDARY_ROLES = IMPLICIT keeps the Default Role field on the connection form functional after the scope change; without it, the OAuth token would be bound to the user's default role and the field would be silently ignored.

Fixes # (issue)

[greptile-apps]

Confidence Score: 5/5

Safe to merge — minimal, well-scoped fix with no logic regressions.

Two-file change: one removes a scope value that Snowflake's own docs confirm is invalid for Custom OAuth integrations, and the other is a patch version bump. No new logic paths, no data-flow changes, and the added SQL parameter (OAUTH_USE_SECONDARY_ROLES = IMPLICIT) is an additive, non-breaking enhancement. No security concerns.

No files require special attention.

Important Files Changed

Filename	Overview
packages/pieces/community/snowflake/src/lib/auth.ts	Removes invalid session:role-any OAuth scope (only valid for External OAuth), adds OAUTH_USE_SECONDARY_ROLES = IMPLICIT to setup SQL and its documentation note so the Default Role field remains functional.
packages/pieces/community/snowflake/package.json	Patch version bump 0.3.1 → 0.3.2, consistent with a bug-fix change.

_{Reviews (1): Last reviewed commit: "fix(snowflake): drop invalid session:rol..." | Re-trigger Greptile}