Large Microsoft Graph presets fail during OpenAPI preview with a generic parse error

[henrik0804]

When trying to add partial OpenAPI specs for microsoft graph API, like #preset=mail on executor cloud it resulted in "Couldn't load or parse this spec: Failed to parse spec".

When I selfhosted this on Cloudflare I noticed the Workers going OOM.

The issue seems to be that graph spec is correctly resolved and returned for input with keepPathItem, but the preview path drops it, so previewSpecText parses the whole document.

I fixed this for my own cf deployment in #1552

However the preview path should probably also implement propper streaming to allow full specs or larger partials to be added aswell, since the full 37mb graph spec would still blow.

==== slop analyisis below ====

The Microsoft adapter is working correctly: providers/microsoft/spec-format-adapter.ts removes the #preset=… fragment, fetches the Graph source, and returns the full source text together with a workload-specific keepPathItem.

The filter was lost at the preview boundary:

1. react/AddOpenApiIntegration.tsx automatically calls the preview endpoint.
2. sdk/plugin.ts resolves the adapter output but called previewSpecText(resolved.specText) without forwarding resolved.keepPathItem.
3. sdk/preview.ts consequently called parse(specText) and extract(doc) on the complete 37 MB Graph document.
4. This materialized the full YAML tree, all operations, and component schemas, exceeding the Workers memory limit. The resulting OOM surfaced as the generic Failed to parse spec error.

Persistence did not have this problem: sdk/backing.ts passes keepPathItem into streamOperationBindingsFromStructure in sdk/extract.ts, which parses and discards path items individually.

PR #1552 fixes partial presets by preserving the filter and structurally reducing the document before preview extraction.

Follow-up

Preview itself should be made fully streaming:

• Retain only lightweight operation metadata during the first pass.
• Rank health-check candidates.
• Re-scan only candidates requiring response-schema projection.

This is necessary for full Graph and other broad selections, because materializing an entire filtered document can still exceed Workers memory limits.