Skip to content

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

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

    B18bugSomething isn't workings.mediumMedium level severity

    Type

    No type

    Projects

    Status
    ToDo
    Status
    Todo

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions