Unable to connect Last.fm account: getToken response: expected value at line 1 column 1

[Shnxxx]

What happened?

Steps to reproduce:

1. Open settings and navigate to the Integrations tab.
2. Click on the Connect button next to Last.fm Scrobbling.

Expected behavior:
The app should initiate the Last.fm sign-in flow (such as opening a browser window to authenticate the account).

Actual behavior:
The connection fails immediately. A toast notification appears in the bottom right corner showing the following error:

Couldn't start Last.fm sign-in: unexpected getToken response: expected value at line 1 column 1

App version

0.4.7

Platform

Windows

OS version / distro

Windows 11 25H2 (Build 26200.8893)

Account state

Signed in (Free)

Logs / screenshots

[Shnxxx]

After debugging and investigating for some time, I traced the authentication flow through:

Integrations → lastfm_begin_auth → get_token() → Last.fm auth.getToken

Based on the tracing and code inspection, the failure appears to be happening while parsing the response returned by Last.fm's auth.getToken request.

The error:

unexpected getToken response: expected value at line 1 column 1

comes directly from:

serde_json::from_str::<TokenResp>(&body)

which indicates that the response body is not being parsed as valid JSON.

I also checked the request construction and signing logic. format=json is already being added to the request, and the api_sig generation appears to follow Last.fm's signing requirements: parameters are sorted, concatenated as key + value, the shared secret is appended, and format/api_sig are excluded from the signature.

Because of that, I think the main issue is that the current implementation doesn't expose enough information about the actual auth.getToken response. It reads the response body and immediately attempts to deserialize it, so an HTML response, XML response, empty body, or other unexpected response all end up as the same generic JSON parsing error.

The current code essentially does:

let body = client
    .get(API_ROOT)
    .query(&params)
    .send()
    .await?
    .text()
    .await?;

check_api_error(&body)?;

serde_json::from_str::<TokenResp>(&body)

A better approach would be to inspect and validate the HTTP response before parsing it, including the status code and Content-Type, and include the response body in the error when deserialization fails.

For example:

let response = client
    .get(API_ROOT)
    .query(&params)
    .send()
    .await
    .map_err(|e| format!("network error: {e}"))?;

let status = response.status();
let content_type = response
    .headers()
    .get(reqwest::header::CONTENT_TYPE)
    .and_then(|v| v.to_str().ok())
    .unwrap_or("<unknown>")
    .to_string();

let body = response
    .text()
    .await
    .map_err(|e| format!("read error: {e}"))?;

if !status.is_success() {
    return Err(format!(
        "Last.fm getToken HTTP {} ({}): {}",
        status,
        content_type,
        body
    ));
}

check_api_error(&body)
    .map_err(|(c, m)| format!("Last.fm error {c}: {m}"))?;

#[derive(Deserialize)]
struct TokenResp {
    token: String,
}

serde_json::from_str::<TokenResp>(&body)
    .map(|t| t.token)
    .map_err(|e| {
        format!(
            "unexpected getToken response: {} (content-type: {}; body: {:?})",
            e,
            content_type,
            body
        )
    })

I also noticed that check_api_error() currently treats any response that doesn't match the expected error structure as successful:

fn check_api_error(body: &str) -> Result<(), (u32, String)> {
    match serde_json::from_str::<ApiError>(body) {
        Ok(e) => Err((e.error, e.message)),
        Err(_) => Ok(()),
    }
}

That could make unexpected or malformed responses harder to diagnose. It would be safer to distinguish between:

valid success response
valid Last.fm API error
invalid / unexpected response

So my current suspicion is that the authentication request itself is reaching something, but the response coming back from auth.getToken is not the JSON payload the code expects. The first fix I'd make is improving the response validation/error reporting so we can see the exact status, content type, and body returned by Last.fm. That should make the underlying cause immediately apparent and prevent this generic expected value at line 1 column 1 error from hiding it.