zed-industries/zed · error

token has expired

Error message

token has expired

What it means

In LiveKit token validation (validate_with_timestamp_source): the JWT signature decoded successfully but its `exp` claim is earlier than the current timestamp (from the injected timestamp source), meaning the token's validity window has passed and it must not be accepted.

Source

Thrown at crates/livekit_api/src/token.rs:174

#[cfg(any(test, feature = "test-support"))]
pub fn validate_with_timestamp_source<'a>(
    token: &'a str,
    secret_key: &str,
    timestamp_source: &dyn UnixTimestampSource,
) -> Result<ClaimGrants<'a>> {
    let mut validation = Validation::default();
    validation.validate_exp = false;
    validation.validate_nbf = false;
    let token: jsonwebtoken::TokenData<ClaimGrants<'_>> = jsonwebtoken::decode(
        token,
        &DecodingKey::from_secret(secret_key.as_ref()),
        &validation,
    )?;
    let claims = token.claims;
    let timestamp = timestamp_source.unix_timestamp()?;

    anyhow::ensure!(claims.nbf <= timestamp, "token is not yet valid");
    anyhow::ensure!(claims.exp > timestamp, "token has expired");

    Ok(claims)
}

#[cfg(test)]
mod tests {
    use super::*;
    use crate::{Client as _, LiveKitClient};
    use std::sync::Arc;

    const ISSUED_AT: u64 = 1_234_567;

    struct FixedUnixTimestampSource(u64);

    impl UnixTimestampSource for FixedUnixTimestampSource {
        fn unix_timestamp(&self) -> Result<u64> {
            Ok(self.0)
        }

View on GitHub (pinned to f4178619ac)

Solutions

  1. Mint a fresh LiveKit token with a later exp
  2. Extend token TTL on the issuing side if tokens expire during sessions
Defensive patterns

Strategy: validation

When it happens

Trigger: Thrown at crates/livekit_api/src/token.rs:174 when the library encounters an invalid state.

Common situations: See trigger scenarios.


AI-assisted analysis of zed-industries/zed@f4178619ac (2026-08-20). Data as JSON: /api/errors/cf7e010929bf4ff5. Report an issue: GitHub.