Checked for duplicates
Yes - I've already checked
🐛 Describe the bug
The API returns metadata.* fields in product responses (e.g. metadata.label_url, metadata.ops:Label_File_Info.ops:file_ref), giving users the reasonable expectation that these field names can be used in q= queries. They cannot.
When a user attempts to query using a metadata.* field name, they get empty results rather than a helpful error. The user must instead know the underlying OpenSearch field name (e.g. ops:Label_File_Info.ops:file_ref) to form a working query — this mapping is not documented and not discoverable.
📜 To Reproduce
Attempt to query using a metadata.* field that appears in the product response:
GET /products?q=(metadata.label_url like "/mars*")
Expected: matching products, or at minimum a descriptive error
Actual: empty result set
🕵️ Expected behavior
Either:
metadata.* field names in q= queries are transparently mapped to their underlying registry field equivalents, or
- A clear error is returned explaining the field name is not directly queryable with a pointer to the equivalent field
📚 Version of Software Used
Current production (https://pds.mcp.nasa.gov/api/search/1)
🩺 Test Data / Additional context
Real-world operational impact: Geo and NSSDCA nodes have hundreds of products with relative paths incorrectly set in metadata.label_url. They need to query for these products in bulk to identify and remediate them. The query they naturally reach for:
GET /products?q=(metadata.label_url like "/mars*")
returns no results. The workaround identified by @tsoliman is to use the underlying field name:
GET /products?q=(ops:Label_File_Info.ops:file_ref like "/mars*")
However this also currently fails due to the separate like operator bug (see #170). The combination of these two issues makes it impossible to perform this class of query via the public API.
Note: This issue is distinct from #170 (the like operator bug). Even with eq, metadata.* fields return no results when used in q=:
GET /products?q=(metadata.label_url eq "some_value") # returns empty, not what the user expects
🦄 Related requirements
⚙️ Engineering Details
The metadata.* fields in API responses are a view-layer transformation from underlying registry fields. The q= query layer does not perform the reverse mapping, so queries against metadata.* names hit non-existent fields and silently return empty.
Fix options:
- Translate
metadata.* field names in incoming q= parameters to their underlying registry equivalents before query execution
- Document the mapping clearly and return a 400 with a helpful message when a
metadata.* field name is used in a query
🤖 Generated with Claude Code
Checked for duplicates
Yes - I've already checked
🐛 Describe the bug
The API returns
metadata.*fields in product responses (e.g.metadata.label_url,metadata.ops:Label_File_Info.ops:file_ref), giving users the reasonable expectation that these field names can be used inq=queries. They cannot.When a user attempts to query using a
metadata.*field name, they get empty results rather than a helpful error. The user must instead know the underlying OpenSearch field name (e.g.ops:Label_File_Info.ops:file_ref) to form a working query — this mapping is not documented and not discoverable.📜 To Reproduce
Attempt to query using a
metadata.*field that appears in the product response:Expected: matching products, or at minimum a descriptive error
Actual: empty result set
🕵️ Expected behavior
Either:
metadata.*field names inq=queries are transparently mapped to their underlying registry field equivalents, or📚 Version of Software Used
Current production (https://pds.mcp.nasa.gov/api/search/1)
🩺 Test Data / Additional context
Real-world operational impact: Geo and NSSDCA nodes have hundreds of products with relative paths incorrectly set in
metadata.label_url. They need to query for these products in bulk to identify and remediate them. The query they naturally reach for:returns no results. The workaround identified by @tsoliman is to use the underlying field name:
However this also currently fails due to the separate
likeoperator bug (see #170). The combination of these two issues makes it impossible to perform this class of query via the public API.Note: This issue is distinct from #170 (the
likeoperator bug). Even witheq,metadata.*fields return no results when used inq=:🦄 Related requirements
likeoperator does not work — separate but compounds this issue)⚙️ Engineering Details
The
metadata.*fields in API responses are a view-layer transformation from underlying registry fields. Theq=query layer does not perform the reverse mapping, so queries againstmetadata.*names hit non-existent fields and silently return empty.Fix options:
metadata.*field names in incomingq=parameters to their underlying registry equivalents before query executionmetadata.*field name is used in a query