https://www.boundaryml.com logo
Vertex with Application Default Credentials not wo...
# help
c
When I use vertex in playground i get:
Copy code
Unspecified error code: 2 Failed to create request builder: Error {
    context: "Failed to build request",
    source: Error {
        context: "Failed to load GCP creds: try running `gcloud auth application-default login`",
        source: JsCallbackRuntimeError {
            name: "Error",
            message: "Unable to detect a Project Id in the current environment. \nTo learn more about authentication and Google APIs, visit: \nhttps://cloud.google.com/docs/authentication/getting-started",
        },
    },
}

Request options: {}
But I can use
uv run baml-cli test
just fine.
v
Oh! @aaronv (BAML) or @lucablight4200 do yall know what the solution was?
a
Do you use a vertex api key or application credentials?
If you use a vertex api key we just added support for it: options { query_params { key env.VERTEX_API_KEY ….
In the vertex client definition
Then add that to the playground env vars
c
We use application defaulty credentials
We have a general policy to restrict the use of api keys as they present a more significant risk if compromised than the short lived application credentials. I can get an exemption but it would be much nicer if I could use ADC
Does the Playground riun in some kind of sandboxed environment? When we run dockerised sandboxed environments that need vertex access we moun the credentials directory as read only and then the clients all work seamlessly
This usually means mounting
~/.config}/gcloud
in the host system into
~/.config/gcloud
in the sandboxed environment
a
i think there's an inherent bug in our playground reading the application credentials correctly. Let me see
and the playground doesn't run in a sandbox -- it's just a webview running from the vscode process
alternatively, to unblock yourself, try using
baml-cli test
it has a way to filter out tests, etc. If stuff is missing from the output you can let us know and we can improve it
if your terminal has the right creds / gcloud auth set it should run fine
c
thanks - i have baml-cli test running and am using that alongside my other unit tests. But hte playground is a nice feature so would be lovely to get it working šŸ™‚
Let me know if I can try anything
a
i run into the same error so i think i have enough of a repro to try to fix it, but no ETA yet. If you do want the playground definitely try the api key approach (if you can manage to get an exception). We just made that work in 0.208.5
b
The playground loads gcloud credentials using the IDE process in vscode edit: after refreshing my gcloud creds, our gcloud integration doesn't work for me, so I'll be looking at this tomorrow
Can you clarify what you mean by ā€œdockerized sandboxed envā€ - is that vscode with a devcontainer?
v
OHHH, are you spawning a repo thats in a container from vscode? if so, i think whats happening is the
shell
command we use to get auth is running in the docker container. which in turn now needs to run
gcloud auth login
or something of that sort which then require the
~/.config/gcloud
file to then exist in that shell (which happens to be in the container)
b
a
this has been released
c
Thanks for the quick turnaround! Correction: everything is working - looks like the Google auth client had cached bad creds. Thank you for your help! ~~ I am still getting an error though: Unspecified error code: 2 Failed to create request builder: Error { context: "Failed to build request", source: Error { context: "Failed to load GCP creds token: try running `gcloud auth application-default login`", source: JsCallbackTypeError( "loadGcpCreds rejected during promise await with Error: VSCode RPC request timed out after 5000ms: LOAD_GCP_CREDS", ), }, } Request options: {"generationConfig":{"temperature":0.0}} ~~
I have vscode runtime 0.210.0
b
are you developing inside a container/ssh?
or something else
c
Nope - this is all in vscode on a Mac. Vscode opened as a regular Mac app. I can run the BAML tests from the vscode terminal or elsewhere just fine.
I rely on the standard gcloud application default credentials store in ~, nothing special setup there
Working now! Looks like restarting the playground plugin and vscode doesn’t seem to reload the credentials after an auth? But the playground is working, which is the key thing
b
> Looks like restarting the playground plugin and vscode doesn’t seem to reload the credentials after an auth? huh. what did you have to reload to make it work?
glad we got you working though!
c
Just time I think - I think the cached token would hit its expiry and then get refreshed
We see similar with other libraries using gcloud auth libs
With cline you can open and close the settings to force a reload
b
Blegh… I’ve definitely ran into similar with AWS before
I wonder if there’s something we can do to force invalidate gcp creds