Repository navigation
Make CreateFilteredDocument filter out unused components #2665
Description
Is your feature request related to a problem? Please describe.
Currently, the CreateFilteredDocument method doesn't filter out any component that is left over after filtering out operations.
Describe the solution you'd like
FilterDocumentOptions type or something similar that allows me to have a more advanced filtering behavior. Which should have a revamped copy implementation:
Additional context
Try to filter the Graph API spec from https://raw.githubusercontent.com/microsoftgraph/msgraph-metadata/refs/heads/master/openapi/v1.0/openapi.yaml with the current implementation to get a clear picture as to why it's an issue. It leaves so many components (particularly the schemas) it's just not practical to use at the moment.
Activity
baywet commentedon Jan 6, 2026
Hi Erwin (@erwinkramer)
Thank you for using the SDK and for reaching out.
This should be fairly simple to implement:
All of that needs to happen after the copy references has happened for structural reasons.
Is this something you'd like to submit a pull request for provided some guidance?
erwinkramer commentedon Jan 6, 2026
Thanks for your response Vincent Biret (@baywet).
Short term I have no interest in picking this up.
Regarding your implementation steps, they look good. However, did u consider that components also reference components, which in turn might or might not be referenced in an actual path inside the document? That makes it a little bit more complex but probably overcomeable.
baywet commentedon Jan 14, 2026
Thank you for the additional information.
I did spend quite some time looking into this further. I can confirm that the library is already doing the most filtering it can do today. You can see my exploration of the matter in the feat/better-schemas-trimming branch (to compare against support/v2).
Essentially if you take the full V1 API description for Microsoft Graph (the one you linked), it contains 4292 component schemas.
If you use hidi to trim it down to only get messages related operations, you'll get about 2896 schemas
Why so many schemas remain? Well that's because the Graph API is designed with a Graph nature in mind (models are highly interconnected), and also because of limitations of the design language for the API. (CSDL). For example, the user model has a "joinedTeams" property, that links it to the teams models in our scenario. But even with the full API surface, there's no way you can retrieve BOTH the user and its joined teams in a single request.
The next question becomes then: why can't we have a version of the description that DOES NOT contain those "unhelpful" properties? There was at some point a division wide effort to improve that aspect of the metadata. A couple of things to note: I changed divisions back in august, so I might not know the latest and greatest on the topic. That effort was de-prioritized in favour of other investments. And even if it were re-prioritized, we're talking about thousands of such properties to annotate properly, it would take a while to see any meaningful impact. In any case, the repository to discuss about this is this one https://github.com/microsoftgraph/msgraph-metadata
Hopefully that high level explanation was clear.
Let me know if you have any additional comments or questions.
erwinkramer commentedon Jan 14, 2026
Thanks for giving such deep insights. I couldn't really believe that so many schemas are linked together at first, until i tried to follow some references for a bit longer. Now it makes more sense.