CDN URLs Missing from Referenced Documents - Urgent Production Issue

I completely understand the urgency of this situation - having your users unable to download audiobooks is a critical issue. Let me help you troubleshoot this systematically.

Most Likely Cause: API Version Configuration

Based on your symptoms (references suddenly not resolving, missing CDN URLs in illustration objects), the most probable cause is related to how your Sanity client is configured, particularly around API versioning.

What May Have Changed

If you weren't explicitly setting an apiVersion in your Sanity client configuration, your application may have started defaulting to a newer API version. Sanity uses a date-based API versioning system, and when no version is specified, the behavior can change when new versions are released.

The most recent API version (v2025-02-19, released February 24, 2025) includes a significant change: the default perspective switched from raw to published. Depending on when you're experiencing this issue, this could be relevant - but regardless, the principle remains the same for any API version change.

Immediate Fix Options

Option 1: Explicitly lock to a stable API version (fastest way to restore service):

const client = createClient({
  projectId: 'your-project-id',
  dataset: 'your-dataset',
  apiVersion: '2024-05-01', // or another stable date you know worked
  useCdn: true,
})

Option 2: Explicitly set the perspective to raw:

const client = createClient({
  projectId: 'your-project-id',
  dataset: 'your-dataset',
  apiVersion: '2024-05-01', // use a specific version
  perspective: 'raw', // explicitly request all content including drafts
  useCdn: true,
})

Additional Troubleshooting Steps

1. Check your illustration documents' publish status: In Sanity Studio, verify that all referenced illustration documents are actually published (not just saved as drafts). If your queries are now using a published perspective, they won't resolve references to draft-only documents.

2. Verify your GROQ query structure: Make sure your query properly dereferences the asset reference. A working query should look something like:

   *[_type == "audiobook"] {
     title,
     illustrations[]-> {
       _id,
       title,
       asset-> {
         _id,
         url
       }
     }
   }

3. Check all client instances: Verify that ALL places where you instantiate Sanity clients (frontend, backend, iOS app, Android app) have the same configuration. An inconsistency here could explain why it's affecting all platforms.

4. Review Sanity's status page: Visit status.sanity.io to check for any ongoing service incidents or outages.

5. Inspect the actual data structure: Use Sanity's Vision plugin in your Studio to run your query and see exactly what data structure is being returned. This will help confirm whether the issue is with the query, the data structure, or the client configuration.

Why References Might Not Resolve

The Image Pipeline serves images through cdn.sanity.io URLs that are constructed from asset references. When references don't resolve properly, the asset object (which contains the url field) won't be included in your query results. This typically happens when:

• The perspective setting doesn't match your content's publish state
• The GROQ query doesn't properly dereference the reference (missing ->)
• The referenced documents don't exist or aren't accessible with the current query configuration

Next Steps

1. Deploy the fix immediately - add explicit apiVersion to all your Sanity client configurations
2. Test on staging first if possible, but given the urgency, you may need to go straight to production
3. Monitor the results - check if audiobooks become downloadable again
4. Document your configuration - ensure your apiVersion is explicitly set going forward to prevent automatic upgrades

The fix should be a quick configuration change that you can deploy across all platforms. Since you mentioned this is affecting both production and staging identically, and you haven't changed anything on your side, this strongly suggests an API version or configuration issue rather than a code bug.

Please try these fixes and let me know if this resolves the issue. If not, share your GROQ query and client configuration (with sensitive data removed) so we can dig deeper!