[Detail Bug] CLI: Token source missing from error message when SDK init fails due to invalid access token header value

[detail-app]

Detail Bug Report

https://app.detail.dev/org_89d327b3-b883-4365-b6a3-46b6701342a9/bugs/bug_b13f6988-21e4-4ea0-88fa-9773d6a42324

Summary

• Context: The CLI's main.rs initializes the SDK client and computes the access token source to provide helpful error messages when authentication/authorization fails.
• Bug: The access_token_source is computed AFTER SDK initialization, so if SDK initialization fails (e.g., due to an invalid access token format), the token source information is not available for the error message.
• Actual vs. expected: When SDK initialization fails due to token-related issues, users get a generic error without guidance on where their token came from. Users should get a helpful message indicating whether to check their config file or environment variable.
• Impact: Users with invalid tokens in environment variables or config files get less helpful error messages, making it harder to diagnose and fix authentication issues.

Code with Bug

In cli/src/main.rs:

let cli_config = load_cli_config()?;
let sdk_config = sdk_config(&cli_config)?;
let s2 = S2::new(sdk_config.clone()).map_err(CliError::SdkInit)?;  // <-- BUG 🔴 If this fails, next line never executes
let token_source = access_token_source(&cli_config);
let result: Result<(), CliError> = (async {
    // ... command handling ...
    Ok(())
})
.await;

result.map_err(|err| err.with_token_source(token_source))  // <-- token_source not available if SDK init failed

Explanation

• S2::new() can fail during client initialization when building the HTTP Authorization header: invalid token characters (e.g., newline/control chars, non-ASCII) can cause try_into()? to return InvalidHeaderValue.
• Because token_source is computed after S2::new(...), an SDK init failure returns early and bypasses the later with_token_source(...) annotation step. As a result, init-time token-related failures show only a generic SDK init error without indicating whether the token came from the environment variable vs config file.

Recommended Fix

• Compute token_source before calling S2::new(...).
• Ensure SDK init errors can be annotated with token source (e.g., extend with_token_source to handle CliError::SdkInit for token-related failures, or always include token source for SDK init errors).

History

This bug was introduced in commit 480f293. The commit added functionality to surface the access token source (environment variable vs config file) in error messages to help users debug authentication issues, but the access_token_source(&cli_config) call was placed after SDK initialization, meaning SDK init failures cause an early return before the token source is computed, preventing users from getting the helpful context the feature was meant to provide.