ClientError: Subscript ranges must have integer endpoints in Sanity

This error is happening because GROQ has restrictions on what can be used in array subscript ranges. Based on a GitHub issue from the Sanity team, this is actually intentional behavior in Sanity's GROQ implementation, even though it works differently in groq.dev.

The error "Subscript ranges must have integer endpoints" occurs when you try to use document fields or expressions as endpoints in array slicing operations. According to the GROQ syntax documentation:

Due to parser ambiguity with filters, the following access operators can only take literals, not arbitrary expressions: array element access (e.g. array[0]), array slices (e.g. array[1..3]), and object attribute access (e.g. object["attribute"]).

This means you can't do things like:

• array[0...postCount] ❌
• array[0...^.postCount] ❌
• array[0...@.postCount] ❌

You can only use literal numbers:

• array[0...5] ✅
• array[1..3] ✅

Why does groq.dev work differently? The JavaScript implementation of GROQ (used by groq.dev) predates this design decision and accepts expressions. However, Sanity's production API enforces the stricter syntax to avoid parser ambiguity.

Workarounds:

1. Use literal values: If you know the count, hardcode it: *[_type == "post"][0...3]
2. Filter after fetching: Fetch all items and handle limiting in your frontend code
3. Restructure your query: Instead of dynamic slicing, use filters to achieve similar results

If you're suddenly seeing this error after it was working, you may have:

• Updated your @sanity/client version (newer versions are stricter)
• Changed from using groq.dev to actual API calls
• Modified your query to use dynamic values in slices

The Sanity team mentioned this could potentially be revisited in the future, but for now it's a deliberate limitation. Check all your GROQ queries for array slicing operations ([n..m] or [n...m]) and make sure they only use literal integer values, not variables or field references.