Skip to content

metadata.* fields returned in product responses are not usable in q= queries #774

@jordanpadams

Description

@jordanpadams

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:

  1. metadata.* field names in q= queries are transparently mapped to their underlying registry field equivalents, or
  2. 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:

  1. Translate metadata.* field names in incoming q= parameters to their underlying registry equivalents before query execution
  2. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workings.highHigh severity

    Type

    No type
    No fields configured for issues without a type.

    Projects

    Status
    ToDo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions