Expose a query API to expose metadata #1750

Activity

1. Brandon Poe (Bpoe)

   added

   Issue-EnhancementThe issue is a feature or ideaThe issue is a feature or idea

   Needs Triage

   on Oct 9, 2026
2. michaeltlombardi commented on Oct 9, 2026

   

   Mikey Lombardi (He/Him) (michaeltlombardi)

   on Oct 9, 2026

   Collaborator

   More actions

   Can you give an example of which metadata field you want to retrieve? The root metadata in a configuration document, or for a resource instance in a configuration document, or for the return data from a resource invocation during a configuration operation?

   It would be really useful to have a snippet for the document and the data you want to extract. I'm not sure what sort of query API you're looking for.

   I am guessing you can't just use native queries in your language of choice to retrieve the data you're looking for because you want the resolved expression for a given field in the metadata?
3. Bpoe commented on Oct 9, 2026

   

   Brandon Poe (Bpoe)

   on Oct 9, 2026

   CollaboratorAuthor

   More actions

   I'm building essentially an LCM. I need some additional information about how to process a configuration. Right now, the only extra information I need is whether it should be a test or set operation, but I assume that will expand later. I'm currently doing that with a separate json document that live next to the configuration document, but Steve suggested I use metadata and I like that approach. The only downside is now my tool needs to learn how to parse a config file, which it didn't need to before. It would be better if I could still consider the file an opaque blob. Here's an example metadata of what I'm thinking. The dscd section is what I care about, but I'm also fine with just receiving the entire metadata section as json. At least then I don't have to pivot on json vs yaml or adapt to any schema changes that might come later.

   $schema: https://aka.ms/dsc/schemas/v3/bundled/config/document.json
   
   metadata:
     dscd:
       operation: test
   
   parameters:
     message:
       type: string
       defaultValue: Hello from template file
   
   resources:
     - name: Echo parameter
       type: Microsoft.Filesystem.File/Content
       properties:
         path: c:\temp\hello-dsc.txt
         content: "[parameters('message')]"
   
4. michaeltlombardi commented on Oct 9, 2026

   

   Mikey Lombardi (He/Him) (michaeltlombardi)

   on Oct 9, 2026

   Collaborator

   More actions

   If you primarily care about the metadata field, I think it's possible to add a server endpoint that extracts it. We've previously discussed adding support for JQLang filters. The downside is a fairly complex additional dependency (supporting a query language) but the upside is that it's a growing industry standard and fairly usable.

   An endpoint like that might look like passing the document, the query string, and an optional flag for whether the server should resolve expressions in the return data (defaulting to not).

   In your example case, the JQ filter would be .metadata.dscd - you can see an example in the jq playground.
5. Steve Lee (SteveL-MSFT)

   self-assigned this

   on Oct 27, 2026