xai-org/x-algorithm · error · anyhow::Error

Rust VF filter_tweets error: {status}

Error message

Rust VF filter_tweets error: {status}

What it means

Produced by rpc_error_map, which converts a failed gRPC filter_tweets call into a HashMap where every requested tweet_id maps to Err("Rust VF filter_tweets error: {status}"). It represents a whole-batch RPC failure — the VF gRPC endpoint itself errored, so no tweet could be evaluated.

Source

Thrown at visibility-filtering-client/vf_client.rs:342

        .map(|r| (r.tweet_id, Ok(result_to_reason(r))))
        .collect();
    for &tweet_id in requested_tweet_ids {
        map.entry(tweet_id)
            .or_insert_with(|| Ok(Some(FilteredReason::UnspecifiedReason)));
    }
    map
}

fn rpc_error_map(
    tweet_ids: &[u64],
    status: &tonic::Status,
) -> HashMap<u64, Result<Option<FilteredReason>>> {
    tweet_ids
        .iter()
        .map(|&tweet_id| {
            (
                tweet_id,
                Err(anyhow!("Rust VF filter_tweets error: {status}")),
            )
        })
        .collect()
}

fn classify_filter_tweets_error_code(code: tonic::Code) -> &'static str {
    match code {
        tonic::Code::DeadlineExceeded => "deadline_exceeded",
        tonic::Code::Cancelled => "cancelled",
        tonic::Code::Unavailable => "unavailable",
        _ => "other",
    }
}

#[derive(Debug, Default, PartialEq, Eq)]
struct FilterTweetsClientMetrics {
    error_codes: Vec<&'static str>,
    failed_ids: u64,

View on GitHub (pinned to 24c60942c5)

Solutions

  1. Retry with backoff for transient codes (UNAVAILABLE, DEADLINE_EXCEEDED) and shrink the batch size if deadlines keep hitting
  2. Check VF service health and the gRPC status string in the message for the specific code
  3. Verify auth metadata/credentials attached to the VF channel
  4. Increase the RPC deadline for large tweet_id batches

Example fix

// before
let results = client.filter_tweets(ids).await
    .unwrap_or_else(|status| rpc_error_map(&ids, &status));

// after
let results = match client.filter_tweets(ids).await {
    Ok(r) => r,
    Err(status) if status.code() == tonic::Code::Unavailable => {
        tokio::time::sleep(Duration::from_millis(250)).await;
        client.filter_tweets(ids).await
            .unwrap_or_else(|status| rpc_error_map(&ids, &status))
    }
    Err(status) => rpc_error_map(&ids, &status),
};
Defensive patterns

Strategy: retry

Validate before calling

null

Try / catch

match vf_call(ids).await { Err(status) if matches!(status.code(), tonic::Code::Unavailable | tonic::Code::DeadlineExceeded) => retry_smaller_batch(...).await, r => r.unwrap_or_else(|s| rpc_error_map(&ids, &s)) }

Prevention

When it happens

Trigger: Calling get_result when the underlying tonic/gRPC filter_tweets RPC returns a non-OK status: UNAVAILABLE (VF service down), DEADLINE_EXCEEDED, UNAUTHENTICATED, PERMISSION_DENIED, or INTERNAL from the VF server.

Common situations: VF service outages or rolling restarts; gRPC deadline too short for large batches; missing/invalid auth metadata; envoy/sidecar issues between client and VF; RESOLUTION failures for the VF endpoint.

Related errors

AI-assisted analysis of xai-org/x-algorithm@24c60942c5 (2026-08-28). Data as JSON: /api/errors/caa7db2aa8892a3e. Report an issue: GitHub.