> ## Documentation Index
> Fetch the complete documentation index at: https://braintrust.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Log filtering with large user ID sets

export const plans_0 = "Any"

export const deployments_0 = "Braintrust-hosted"

export const data_plane_version_0 = undefined

export const use_case_0 = "Use case - BTQL log filtering with more than 128 user IDs or other metadata values"

<Note>
  **Applies to:**

  * Plan - {plans_0}
  * Deployment - {deployments_0}
  * {data_plane_version_0}
  * {use_case_0}
</Note>

## Summary

**Issue:** Filtering logs with chained `OR` operations like `metadata.user_id MATCH 'id1' OR metadata.user_id MATCH 'id2'` fails when exceeding 128 conditions due to a backend JSON nesting recursion limit.

**Cause:** Chained `OR` queries are nested in JSON on the backend and hit the 128 query recursion limit.

**Resolution:** Use the `IN` operator instead of chained `OR` operations to filter by large sets of user IDs.

## Resolution Steps

### Use the IN operator for large ID sets

#### Step 1: Replace chained OR queries with IN operator

Use the `IN` operator for filtering metadata fields.

```text theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}}
metadata.user_id in ('50157c3d-edd9-4287-85ee-48c119967099', 'a3fe059a-e4f4-4e9f-b3e3-0da04ed1f075', '913b6ae1-72aa-4113-964e-e41364933a43')
```

#### Step 2: Verify query performance

The `IN` operator supports 300+ IDs and avoids the recursion limit entirely.

### Alternative: Use the API for programmatic filtering

#### Step 1: Query logs via Braintrust API

Use the Braintrust API to fetch and filter logs programmatically if the `IN` operator doesn't meet your requirements.