feat: make gcp auth work seamlessly from vscode

[sxlijin]

Implement loading GCP oauth token via a JS callback using the gcp node sdk, saving users from having to create a service account and put the secret key in an env var to use the playground.

Also convert from using a DI-esque pattern where things are wired through RuntimeContext to instead using a singleton pattern which uses channels to mimic RPCs across the wasm/js boundary to drive the callbacks (necessary because of the Send requirements that tokio imposes on js_sys::Value which is not Send).

TODO:

• - test the errors - what happens when the user is not gcloud auth'd? is the error message good?
• - restore the vertex wasm_auth path when env vars are explicitly set
• - fix this error (explicit env var should never resolve to file in wasm) "Failed to auth - cannot load credentials from a file in WASM (path='$INTE...', path.len=51)",
• - fix this error (explicit env var should have a useful error) "Failed to auth - cannot load credentials from a file in WASM (path='$INTE...', path.len=51)",
• - try to drop the custom result enums
• - rename aws* to js-callback-bridge*
• - update docs (both this and the vertex docs saying that claude is not supported)

Fixes #1857

---

Important

Add seamless GCP OAuth token loading in VSCode and refactor AWS credential handling to use a unified callback bridge.

• Behavior:
  • Implement GCP OAuth token loading via JS callback using GCP Node SDK, removing need for service account setup.
  • Refactor AWS credential handling to use a unified callback bridge for both AWS and GCP.
• Code Structure:
  • Introduce js_callback_bridge.rs for handling JS callbacks for AWS and GCP credentials.
  • Modify runtime_context.rs and context_manager.rs to remove AWS-specific credential handling.
  • Update WebviewPanelHost.ts to handle new GCP credential requests.
• Misc:
  • Add google-auth-library to package.json for GCP authentication.
  • Remove aws_cred_bridge.rs and replace with js_callback_bridge.rs.
  • Update TypeScript interfaces in vscode-rpc.ts to include GCP credential requests.

^{This description was created by for c65a093. You can customize this summary. It will automatically update as commits are pushed.}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
baml	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 26, 2025 0:43am

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to c65a093 in 2 minutes and 33 seconds. Click for details.

• Reviewed 1314 lines of code in 22 files
• Skipped 1 files when reviewing.
• Skipped posting 23 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. typescript/playground-common/src/shared/baml-project-panel/vscode-rpc.ts:136

• Draft comment:
  This interface is already defined in the vscode-ext package. Consider importing and reusing the existing interface to avoid duplication. - interface LoadGcpCredsRequest (vscode-rpc.ts)
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While code duplication is generally bad, this is a type definition in what appears to be an RPC interface file. These types often need to be defined in multiple places to maintain clean package boundaries and avoid circular dependencies. Without seeing the full codebase architecture, we can't be certain that importing from vscode-ext would be the right approach - it could create unwanted dependencies. The comment could be correct about the duplication, and DRY is generally good practice. Maybe there's a legitimate reason to share these types across packages. However, RPC interface files commonly need independent type definitions on both sides of the boundary. Without understanding the full architecture, suggesting to import from vscode-ext could violate package boundaries. Delete the comment. While it points out potential duplication, we don't have enough context to know if importing from vscode-ext is the right architectural decision.

2. typescript/vscode-ext/packages/vscode/src/vscode-rpc.ts:192

• Draft comment:
  The custom base64 encoding and decoding implementations (lines 193-225) rely on manual bit operations. Consider using built-in browser APIs (e.g. btoa/atob or Buffer in Node) for improved reliability and clarity, unless there is a specific reason for this custom implementation.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

3. typescript/vscode-ext/packages/vscode/src/panels/WebviewPanelHost.ts:361

• Draft comment:
  In the 'LOAD_GCP_CREDS' case (lines 396-441), the error handling repeats similar logic as in the AWS creds case. Consider abstracting common error response handling into a helper method for clarity and to reduce duplication.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

4. typescript/playground-common/src/shared/baml-project-panel/atoms.ts:14

• Draft comment:
  The initialization call wasm.init_js_callback_bridge(vscode.loadAwsCreds, vscode.loadGcpCreds) appears to correctly bridge JS callbacks. Ensure that these callbacks always follow the expected interface and properly handle promise rejections to avoid silent failures.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

5. typescript/vscode-ext/packages/vscode/src/vscode-rpc.ts:118

• Draft comment:
  The type definitions in the VSCode RPC file (lines 120-180) are clear. Verify that any new command added matches the type constraints to ensure type safety between the webview and VSCode extension.
• Reason this comment was not posted:
  Confidence changes required: 30% <= threshold 50% None

6. typescript/playground-common/src/shared/baml-project-panel/atoms.ts:12

• Draft comment:
  Good use of async atom; however, consider adding error handling in case wasm initialization fails (e.g. in the call to init_js_callback_bridge) to help debug issues in non-VSCode environments.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment is about a newly added line of code. Error handling could be valuable since WASM initialization failures can be hard to debug. However, this is inside an async atom where errors would propagate up naturally, and the code has error handling patterns elsewhere. The comment speculates about "non-VSCode environments" without clear evidence this is an issue. I might be underestimating the importance of explicit error handling at this level. WASM initialization errors could be cryptic without proper handling. While error handling is generally good, the async atom pattern will naturally propagate errors, and the codebase already shows established error handling patterns elsewhere. The comment is somewhat speculative about non-VSCode environments. The comment should be removed. While it suggests a reasonable practice, it's more speculative than clearly necessary, and the existing error handling patterns in the codebase seem sufficient.

7. typescript/playground-common/src/shared/baml-project-panel/playground-panel/prompt-preview/test-panel/test-runner.ts:95

• Draft comment:
  There is commented-out debugging code present. Consider removing or cleaning up commented code before merging.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

8. typescript/playground-common/src/shared/baml-project-panel/vscode-rpc.ts:192

• Draft comment:
  Custom base64Encode and decodeBuffer functions are implemented manually. Consider reviewing if built-in browser APIs (like btoa/atob) or Node Buffer methods could simplify or improve performance.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

9. typescript/vscode-ext/packages/vscode/src/panels/WebviewPanelHost.ts:269

• Draft comment:
  Repeated calls to compute file path strings (_uri_str) are made multiple times. Consider caching computed file path strings into a variable to reduce redundancy.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

10. typescript/vscode-ext/packages/vscode/src/vscode-rpc.ts:129

• Draft comment:
  The RPC schema is clearly defined. Ensure that the union types properly handle future extension scenarios, and consider adding inline comments for clarity when new commands are added.
• Reason this comment was not posted:
  Confidence changes required: 40% <= threshold 50% None

11. typescript/vscode-ext/packages/vscode/package.json:11

• Draft comment:
  Package metadata looks solid. Verify that engines.vscode version (^1.63.0) meets minimal requirements; consider bumping if testing shows compatibility with newer VS Code versions.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

12. engine/baml-runtime/src/internal/llm_client/primitive/aws/aws_client.rs:86

• Draft comment:
  Typo: In the error message on line 86, change 'a aws-bedrock property' to 'an aws-bedrock property' for grammatical correctness.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

13. engine/baml-runtime/src/internal/llm_client/primitive/vertex/wasm_auth.rs:61

• Draft comment:
  The log message "got gcp creds from vscode, discarded them because it's really aws creds" could be worded more clearly. For consistency and clarity, consider revising it (perhaps changing 'aws creds' to 'AWS credentials' if that is intended).
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% This is a very minor stylistic suggestion about log message formatting. The current message is clear enough for debugging purposes. The message is also somewhat confusing regardless of formatting since it talks about discarding GCP creds because they're AWS creds - the wording isn't the main issue here. This seems like an overly pedantic comment that doesn't meaningfully improve the code. The comment does point out an inconsistency in terminology which could be confusing to developers. Log messages are part of the developer interface. While consistency in terminology is good, this is an internal debug log message and the current wording is clear enough. The benefit of changing it is minimal. Delete this comment as it's too minor and doesn't meaningfully improve the code quality or functionality.

14. engine/baml-runtime/src/internal/llm_client/primitive/vertex/wasm_auth.rs:107

• Draft comment:
  The log message "got gcp creds from vscode, discarded them because it's really aws creds" appears again. Consider revising it for clarity and consistency (e.g., 'AWS credentials' if that is the intent).
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% The log message is indeed confusing and could be clearer. However, this is just a debug/info log message, not actual code logic. The suggested change is very minor and doesn't affect functionality. Log message clarity is not a critical issue that requires a PR comment. The log message is genuinely confusing and the suggestion would make it clearer. Maybe unclear logging could cause debugging issues later? While clearer logs are nice, this is a very minor stylistic issue. Log message wording doesn't affect functionality and doesn't meet the bar of "clearly requiring a code change" per our rules. Delete this comment as it's about log message wording which is too minor an issue to warrant a PR comment.

15. engine/baml-runtime/src/lib.rs:766

• Draft comment:
  Typo: 'requeset' should be 'request' in the comment about the request body.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

16. engine/baml-runtime/src/lib.rs:1117

• Draft comment:
  Typo: 'functios' should be corrected to 'functions' in the documentation comment describing expression functions.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

17. engine/baml-runtime/src/types/context_manager.rs:126

• Draft comment:
  Typo found in the comment: 'passe dinto call_function()' should be corrected to 'passed into call_function()'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

18. engine/baml-runtime/src/types/runtime_context.rs:60

• Draft comment:
  Typographical error: In the comment on line 60, 'wont' should be corrected to 'won't' to ensure proper grammar.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

19. engine/baml-schema-wasm/src/runtime_wasm/mod.rs:195

• Draft comment:
  It appears that the string 'BAML_PATH_SPLTTER' (used to join the key and value for file content) might be a misspelling. Consider correcting it to 'BAML_PATH_SPLITTER' if that was the intended separator.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

20. engine/baml-schema-wasm/src/runtime_wasm/mod.rs:66

• Draft comment:
  The inline comment on line 66 reads "I dont think we need this line anymore...". Consider changing "dont" to "don't" for correct punctuation.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

21. typescript/playground-common/src/shared/baml-project-panel/atoms.ts:292

• Draft comment:
  Typographical error: The comment on line 292 contains 'we can do somehting fancier'; please correct it to 'something'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

22. typescript/playground-common/src/shared/baml-project-panel/vscode.ts:182

• Draft comment:
  Typographical error: 'Abitrary' should be corrected to 'Arbitrary'. This change will improve the clarity of the code comment.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

23. typescript/vscode-ext/packages/vscode/src/panels/WebviewPanelHost.ts:197

• Draft comment:
  Typo: In the comment describing the message listener, 'recieved' should be corrected to 'received'.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_mFFJWARlj6Rb2Pt6

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}