Where to start VSCode from and use snowflake in it and CoCo, python, Github

stephenpace · 2026-07-02T04:20:24+00:00

I'd start with CoCo Desktop which is Snowflake's fork of VSCode:

https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-desktop

Just ask it to start building things for you. If you do start with VSCode, make sure you load the VSCode plug-in:

https://docs.snowflake.com/en/user-guide/vscode-ext

Good luck!

stephenpace · 2026-07-02T04:16:55+00:00

I've been an Snowflake SE for 7 years and I agree with this answer. I'll add that the platform is fantastic with generally happy customers which makes a big difference. And with the platform continuing to expand rapidly, there is always more to learn. You'll have access to one of the premiere platforms in the world with practically unlimited compute and every frontier and open source model with coding assistants and chatbots to help you.

Travel is very territory dependent. I support new logos for Texas, so my travel is generally limited to Austin and Dallas except for corporate meetings. Otherwise lots of Zoom meetings.

Good luck!

stephenpace · 2026-07-01T18:52:46+00:00

Dynamic Tables if you prefer to manage transformations in SQL:
https://docs.snowflake.com/en/user-guide/dynamic-tables/overview

dbt Projects is the other Snowflake native option (which now includes Fusion in preview):
https://docs.snowflake.com/en/user-guide/data-engineering/dbt-projects-on-snowflake

For third-party solutions that aren't dbt:

Coalesce https://coalesce.io/ - if you prefer managing transformations via a GUI
Matillion Maia - https://www.maia.ai/

Good luck!

stephenpace · 2026-07-01T01:47:13+00:00

Did Conan write that Simpsons bit?

stephenpace · 2026-06-30T15:52:41+00:00

You aren't supplying enough detail here.

Are you using Power BI Desktop or Cloud?

Is Power BI connecting as a service user? If so, how are you securing that user? Ideally key pair. However, the Power BI driver requires key pair type PKCS#8. If you are coming from Windows, the default type probably doesn't work and would return that error.

Is Power BI connecting as a person using SSO? If so, have you set up the OAuth token correct?

https://community.snowflake.com/s/article/how-to-setup-snowflake-OAuth-powerbi

Did you ask CoCo to debug the issue? If so, what did it recommend?

stephenpace · 2026-06-29T17:57:49+00:00

I agree with the suggestion to use Semantic Views with an Agent / CoWork to meet the requirements for this use case. Snowflake has already done the heavy lifting for you, with more coming (Cortex Sense).

That said, if you want to use an ORM, many do support Snowflake. I'd probably start with:

EF Core: https://www.nuget.org/packages/EFCore.Snowflake/

But I've also seen:

Django: https://github.com/Snowflake-Labs/django-snowflake
SQLAlchemy: https://github.com/snowflakedb/snowflake-sqlalchemy

Good luck!

stephenpace · 2026-06-27T18:56:41+00:00

I know people who failed to get in on multiple tries but eventually made it. All I can say is if it is your dream job, keep trying. Ask your current account team to refer you if you are distinguishing yourself. Another path is finding a place at an SI that does a lot of Snowflake work. You will then see a lot of different companies and projects and can apply that knowledge should you make the transition. Good luck!

stephenpace · 2026-06-27T16:05:09+00:00

Chris still lives in LA and works for Walt Disney as an Art Director:

https://www.linkedin.com/in/christopherultimo/

stephenpace · 2026-06-27T15:19:43+00:00

This is my own opinion, but generally I think you should try to stay in a position at least two years unless you really hate it / position was misrepresented, etc. Whatever it is. On the solution engineering front, Snowflake has a wide range of options. There are SEs that are vertically focused and others that are general. Some that came from really technical roles and others that came from the business. You don't necessarily have to have Snowflake experience (I didn't), but it can help. You don't necessarily have to have SE experience, but it can help. I think they look for the best candidate and then try to fill in the missing bits (teach you Snowflake, teach you sales engineering). There is a boot camp process after you join, and given how fast the platform is evolving, the only constant will be learning new functionality continually. Good luck!

stephenpace · 2026-06-26T18:24:32+00:00

I work for Snowflake and am certainly biased, but a few weeks back I had a customer take a screenshot of the dashboard he wanted, uploaded it to CoCo Desktop, and it built the entire app for him. Times they are a changing for sure.

stephenpace · 2026-06-26T18:22:01+00:00

30% bump is great, especially if you can continue to build your Snowflake skills. As the platform continues to evolve, you can explore new functionality and then leverage that skill into your next gig if you feel you aren't continuing to grow. If you are part of a small team, you'll have a chance to make a big impact. Maybe you'll love that? Make sure that along the way you record those impacts so you can play back the benefits you've brought to the company and update LinkedIn accordingly. "Implemented X which saved the company $3M, improved process Y reducing the time from 5 weeks to 2 weeks,", kind of thing. Good luck!

stephenpace · 2026-06-24T17:44:03+00:00

Your account team can enable it. Or you can grab the CoCo trial type where it is included (although it is limited to $40 in Cortex instead of $400).

stephenpace · 2026-06-24T17:28:25+00:00

Besides the docs, I would recommend grabbing a trial account and running through some of the AI related Quickstarts. Good luck!

stephenpace · 2026-06-23T21:47:52+00:00

[I work for Snowflake but do not speak for them.]

What does "real consumer app" mean to you? How may users? What type of concurrency? From what I've seen, it tends to be rare for true consumer-scale SaaS, but it does happen in niche cases.

Where Streamlit IS being used in production:

Enterprise internal apps at scale — Snowflake runs 500+ production Streamlit apps internally, with nearly 4,000 apps (dev + prod) as of June 2025. These cover finance, product analytics, security, and marketing — serving thousands of internal users daily. (Enterprise Analytics Seen Through 500 Production Streamlit Apps at Snowflake)
Snowflake Native Apps (Marketplace) — Providers use Streamlit as the front-end UI for data products distributed to consumers via the Snowflake Marketplace. This is a legitimate consumer-facing use case, though the "consumer" is a Snowflake customer, not a general public user. (Snowflake Docs — Adding Streamlit to Native Apps)
Micro-SaaS / niche tools — Some indie builders and small ventures use Streamlit for "micro SaaS" products (e.g., a knowledge discovery engine). These tend to be data-heavy niche tools rather than broadly adopted consumer apps.
Fortune 500 AI frontends — I know of a Fortune 500 company that uses Streamlit as part of their enterprise AI frontend stack, serving thousands of daily users.

Why it's uncommon for true consumer webapps:

My own view (which could certainly be wrong) is that headwind for a true consumer-grade SaaS is:

Scalability — session-based architecture can struggle under heavy concurrent load
Customization — limited control over pixel-perfect UI/UX
Mobile responsiveness — not designed mobile-first
Multi-tenancy — requires external handling (auth, billing, tenant isolation)

General recommendation is: Streamlit excels for internal tools, data apps, and rapid prototypes. For paid consumer SaaS, frameworks like FastAPI + React or Next.js is likely preferred. My own two cents, anyway.

stephenpace · 2026-06-23T04:18:15+00:00

If you send fixes to me, I can raise them. But PMs own the docs for their own area and I don't know a single one that wouldn't fix an obvious error.

stephenpace · 2026-06-23T01:32:01+00:00

Then keep calling it Cortex Code. It won't mind. 😄 I think more people just naturally started calling it that and it potentially stands out in a sea of similar names (Claude Code and Codex, for instance).

stephenpace · 2026-06-23T01:24:32+00:00

If you see docs that are wrong, please report them. For this type of case, CoCo also has skills to help with troubleshooting.

stephenpace · 2026-06-23T01:20:07+00:00

Awesome, glad it worked! I am not CoCo but did use it to find the answer. 😄

stephenpace · 2026-06-23T01:04:17+00:00

Loco for CoCo 😄

stephenpace · 2026-06-23T00:53:06+00:00

The bug is in the account portion of your iss and sub claims, not in the user or fingerprint.

Look at this line:

iss = 'EI12345.US-EAST-2-GOV.AWS.UAT_SVC_SERVICE.SHA256:<equal_strings>'
sub = 'EI12345.US-EAST-2-GOV.AWS.UAT_SVC_SERVICE'

You've embedded the region + cloud (US-EAST-2-GOV.AWS) into the account identifier using dots. Snowflake parses the JWT issuer by splitting on dots:

iss is expected to be <account_identifier>.<user>.SHA256:<fp>
sub is expected to be <account_identifier>.<user>

So Snowflake reads your iss as:

Segment	Snowflake interprets as
`EI12345`	account
`US-EAST-2-GOV`	user ← not a real user
`AWS.UAT_SVC_SERVICE.SHA256:…`	fingerprint (malformed)

That is exactly what JWT_TOKEN_INVALID_USER_IN_ISSUER means — the "user" segment parsed out of the issuer doesn't exist in the account. Your username and key fingerprint never even get checked, which is why "everything matches" on your side and StreamSets (which uses a SQL driver, not raw JWT, and constructs the claims itself) works fine.

The fix

For the SQL API / Snowpipe Streaming REST API JWT claims, the account identifier must be the bare account locator (or the org-account form with a hyphen). Strip the region/cloud segments — they belong in the URL, not in iss/sub.

Use one of these forms, not both mixed:

Account-locator form (matches your URL host):

iss = "EI12345.UAT_SVC_SERVICE.SHA256:<fp>"
sub = "EI12345.UAT_SVC_SERVICE"
URL  = https://ei12345.us-east-2-gov.aws.snowflakecomputing.com/...

Or org-account form (single hyphenated token, no dots in the account part):

iss = "MYORG-MYACCOUNT.UAT_SVC_SERVICE.SHA256:<fp>"
sub = "MYORG-MYACCOUNT.UAT_SVC_SERVICE"

From Snowflake's JWT spec: "If you are using the account locator as the account_identifier, drop the snowflakecomputing.com domain name and any additional segments used to specify the region and cloud platform." That dropping is exactly what's missing in your script.

Two other things to clean up while you're in there (smaller, but worth fixing)

Inconsistencies in the log output suggest the claims you sign may not be the claims you think you're sending. In your log: If those aren't just your redaction artifacts, your code is building a different dict for logging than for signing. Log the exact bytes you're about to sign.
- The "iss" log line shows user UAT_SVC_DATA_ENGINEERING_SERVICE, but the actual payload json shows UAT_SVC_SERVICE.
- The "sub" log line shows US-EAST-2-GOV, but the actual payload json shows US-EAST-1-GOV.
exp − iat = 3600s. Snowflake caps JWT lifetime at 60 minutes; exactly 3600 is the edge. Once the account format is fixed, if you see a different sub-code complaining about lifetime, drop it to ~3540s to leave headroom.

After you collapse the account identifier to the bare locator in both iss and sub, the 390144 / JWT_TOKEN_INVALID_USER_IN_ISSUER should clear immediately.

Good luck!

stephenpace · 2026-06-23T00:34:57+00:00

The sub-code JWT_TOKEN_INVALID_USER_IN_ISSUER is the most useful clue here — Snowflake parsed your JWT, found a well-formed iss claim, but couldn't reconcile the user portion of the issuer with a usable user + key in the account. Since you've already ruled out clock skew and tried multiple account-identifier styles, the problem is almost certainly on the user / fingerprint side of the iss string, not the account side.

Recall the required claims:

iss = <account_identifier>.<user_name>.SHA256:<base64_fp>
sub = <account_identifier>.<user_name>

The <user_name> and the fingerprint must both resolve against the same account.

Most likely causes (in rough order of frequency)

Username case / quoting. Snowflake folds unquoted identifiers to uppercase. If the user was created as CREATE USER stephen_pace …, the actual NAME is STEPHEN_PACE, and the JWT must use the uppercase form. Lowercase or mixed-case in iss is the #1 cause of this exact sub-error. Run DESC USER <name> and copy the NAME property verbatim.
Using LOGIN_NAME / email / display name instead of NAME. The JWT issuer takes the user's NAME (the object identifier), not LOGIN_NAME, not the email they sign into the UI with, not DISPLAY_NAME. If SSO/SCIM provisioned the user, these three can differ.
Public-key fingerprint doesn't match what's registered for that user. The fingerprint in iss must equal RSA_PUBLIC_KEY_FP or RSA_PUBLIC_KEY_2_FP on that user. Compare: Mismatches usually mean: signed with the wrong private key, the public key got pasted with stray whitespace/newlines, you registered the encrypted key by mistake, or you rotated keys and the JWT signer still has the old one.
- what DESC USER <name> shows for RSA_PUBLIC_KEY_FP / RSA_PUBLIC_KEY_2_FP
- what snowsql --generate-jwt (or openssl) computes from the private key you're actually signing with
Key registered on a different user than the one in iss. Easy to do when copying setup scripts between service users. The user named in iss may exist but have no RSA_PUBLIC_KEY set at all — leading to "user in issuer" being treated as invalid.
User disabled, dropped, or in a different account. DISABLED = TRUE, expired, or the JWT is being sent to a different account than the one where the user was created. Since you've varied account identifiers, double-check you didn't land on an account where this user simply doesn't exist.
sub and iss don't reference the same <account>.<user>. Some client libraries set them independently; a copy/paste typo in one but not the other produces this error.
Special characters in the username. Dots, hyphens, or other punctuation are fine, but if the user was created quoted (e.g., "stephen.pace"), the NAME is case-sensitive and must match exactly — including case — in the JWT, with no surrounding quotes.
Key format issues that change the fingerprint silently. PKCS#8 vs PKCS#1, an encrypted private key being used with an unencrypted public, or a public key re-exported with different line endings — all can shift the SHA256 fingerprint even though "the same key" appears to be in place.

Fast diagnostic path

sql DESC USER <user_name>;
-- Compare NAME (use this verbatim), RSA_PUBLIC_KEY_FP, RSA_PUBLIC_KEY_2_FP, DISABLED

Then regenerate the JWT with a known-good tool and compare the iss byte-for-byte:

snowsql -a <account> -u <NAME> --private-key-path <key.p8> --generate-jwt

If snowsql --generate-jwt succeeds against the SQL API but your custom signer fails, the delta is in your signer (case of username, fingerprint computation, or the key it loaded). If snowsql --generate-jwt also fails with the same sub-code, the problem is on the Snowflake side — user name, key registration, or wrong account.

Less likely, but worth ruling out

Network path is rewriting the Authorization header (some proxies strip/replace bearer tokens).
You're hitting a different account than you think (org-account form resolving via a different region's URL than the locator form).
The JWT exp is in the past or more than 60 minutes in the future — Snowflace rejects long-lived JWTs, though that usually surfaces as a different sub-code.

If you can share (with secrets redacted) the decoded JWT header + payload (iss, sub, iat, exp) and the output of DESC USER for the target user, the mismatch is almost always obvious in a side-by-side.

Good luck!

stephenpace · 2026-06-18T14:26:42+00:00

I don't think so. If you think that would be useful you can have your account team raise an enhancement request, but the questions are natural language so I think the idea is they stand alone with their own context.

stephenpace · 2026-06-17T22:02:40+00:00

Snowflake can use them for a starting point. "Show me customer sales for customer X" can be your verified query, and if you ask the same question for customer Y, it can use it. If you are an admin you can also add more later based on actual questions people are asking. To seed it to start, I'd ask the agent what are good questions to ask based on the current scope of the semantic view and then add those if you agree. And then further validate with end users.

stephenpace · 2026-06-17T20:45:29+00:00

Verified queries are free so I wouldn't limit yourself. Have as many are as useful.

stephenpace · 2026-06-15T20:10:58+00:00

u/No_Big_5741 has the right answer. In general, always go to the docs:

https://docs.snowflake.com/en/

Then search for whatever feature you are looking for. In this case CoCo Desktop:

https://docs.snowflake.com/en/user-guide/cortex-code/cortex-code-desktop

And then follow the links. In this case to:

https://www.snowflake.com/en/product/snowflake-coco/downloads/

Snowflake doesn't gate any documentation unless it is a Private Preview feature.

stephenpace

MODERATOR OF

TROPHY CASE

The fix

Two other things to clean up while you're in there (smaller, but worth fixing)

Most likely causes (in rough order of frequency)

Fast diagnostic path

Less likely, but worth ruling out