Query issue with returning a specific "collection" document in a Slack thread.
Looking at your query, I can help you understand what's happening and provide working solutions. The good news is that both -> and references(^._id) should work together - there's no documented limitation preventing this combination.
Based on the references() function documentation and reference access operator docs, both operators function as expected when combined. The issue you're experiencing is likely related to your specific data structure or how the filters are being evaluated, not a platform limitation.
Understanding what's happening:
Your problematic query combines three conditions:
slug.current == $collectionSlugpartner->slug.current == $partnerSlug(dereferences partner)references(^._id)(checks if collection references the post)
When all three are combined with &&, ALL conditions must be true. If any single condition fails, the entire filter returns no results.
Debugging approach:
First, verify your data structure. Check if your collection document actually has both:
- A
partnerreference field pointing to a partner document - A reference to the post (likely in a
postsarray)
You can test each condition individually:
// Test 1: Does the collection exist with the right slug?
*[_type == 'collection' && slug.current == $collectionSlug]
// Test 2: Does it reference the post?
*[_type == 'collection' && slug.current == $collectionSlug && references("your-post-id")]
// Test 3: Does it have the right partner?
*[_type == 'collection' && slug.current == $collectionSlug && partner->slug.current == $partnerSlug]Working solutions:
Option 1: Filter after dereferencing (most flexible)
Move the partner check outside the main filter using array slice filtering:
*[_type == 'post' && slug.current == $postSlug && partner->slug.current == $partnerSlug] {
"post": @{..., images[]{..., asset->{...}}},
"collection": *[_type == 'collection'
&& slug.current == $collectionSlug
&& references(^._id)
]{
...,
partner->,
posts[]->{..., images[]{..., asset->{...}}}
}[partner.slug.current == $partnerSlug][0],
"partner": *[_type == 'partner' && slug.current == $partnerSlug]{...}[0]
}This approach filters on references(^._id) first, then applies the partner check after dereferencing.
Option 2: Use direct reference comparison
Instead of dereferencing with ->, check the _ref field directly:
*[_type == 'post' && slug.current == $postSlug && partner->slug.current == $partnerSlug] {
"post": @{..., images[]{..., asset->{...}}},
"collection": *[_type == 'collection'
&& slug.current == $collectionSlug
&& partner._ref in *[_type == 'partner' && slug.current == $partnerSlug]._id
&& references(^._id)
]{...}[0]
}Option 3: Validate in application code
Since your second query works, use it and verify the partner relationship in your application:
*[_type == 'post' && slug.current == $postSlug && partner->slug.current == $partnerSlug] {
"post": @{..., images[]{..., asset->{...}}},
"collection": *[_type == 'collection'
&& slug.current == $collectionSlug
&& references(^._id)
]{
...,
partner->{slug},
posts[]->{..., images[]{..., asset->{...}}}
}[0],
"partner": *[_type == 'partner' && slug.current == $partnerSlug]{...}[0]
}Then check collection?.partner?.slug?.current === partnerSlug in your code, returning null if it doesn't match.
Why your other queries work:
- Query 2 (without partner check): Only two conditions to satisfy
- Query 3 (without
references(^._id)): No parent scope reference needed
The key insight is that when combining multiple conditions, each one narrows your result set. The most likely issue is that your collection document structure doesn't match all three conditions simultaneously. Option 1 is generally the most reliable approach as it separates the filtering logic into stages.
Sanity – Build the way you think, not the way your CMS thinks
Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.