deploy_html corrupts large (~650KB+) single-file HTML bundles — content gets swapped between chunk positions

[CuttingEdgeCarl]

Summary

deploy_html (via PK_deploy_html) deterministically corrupts large single-file HTML bundles (~650KB) while writing them into the ProofKitApps.HTML field. The corruption is not a truncation — the stored field length is almost identical to the source file length — it looks like a chunk of content gets written to the wrong position, replacing a different chunk of roughly the same size, rather than being appended.

Environment

• FileMaker Pro 21+ (web viewer uses WebView2 / evergreen Chromium — ruled out as a JS-engine compatibility issue)
• @proofkit/webviewer 3.2.0, @proofkit/fmdapi 5.2.0
• Vite build with vite-plugin-singlefile, producing a single inlined dist/index.html (~656,131 characters)
• Deployed via the deploy_html MCP tool → PK_deploy_html FileMaker script

Symptom

After deploying, the web viewer shows only the background color (nothing renders). DevTools console reports:

data.htm:118 Uncaught SyntaxError: Unexpected identifier '...'

The specific identifier reported changes between builds/deploys of different content, but for a given build the failure is 100% deterministic — redeploying the exact same file produces the identical error at the identical location every time.

Root cause (confirmed)

Ruled out JS syntax compatibility (WebView2 is evergreen; node --check confirms the built dist/index.html's inline <script> is valid modern JS on its own).

Confirmed via direct SQL against the FileMaker file that the stored field is already corrupted before the web viewer ever reads it:

SELECT LENGTH("HTML") FROM "ProofKitApps" WHERE "AppName" = 'my-app'
-- returned 656128

-- source dist/index.html is 656131 characters

Lengths are nearly identical (off by 3, consistent with trivial newline handling) — so this isn't truncation, and it isn't a duplicate-insertion bug either (that would inflate the stored length by however many characters got duplicated). I confirmed via LIKE queries that the stored HTML field contains a corrupted excerpt that does not appear anywhere in the source file, while the correct excerpt from the same offset in the source is entirely absent from the stored field. E.g., at the same logical position, the source has:

p_=e=>e===hE?`�${ug}`:e,g_=({ariaLabel:e,value:t,onValueChange:r,isNew:i,onIsNew...

but the stored/served content at that position instead contains a large block of unrelated content taken from much further along in the same file (~tens of KB of Tailwind's internal class-config object plus dozens of unrelated component definitions), which itself also appears again, correctly, later in the file. So a chunk-sized region is effectively replaced by a duplicate of a different chunk, rather than anything being lost outright.

This strongly suggests PK_deploy_html (or whatever transport layer feeds it a large payload) splits the HTML into chunks for storage/transport and has an indexing bug that, above some size threshold, writes one chunk's content into another chunk's position.

Reproduction

1. Build a ProofKit web viewer app whose single-file bundle is roughly 650KB+.
2. deploy_html it into a FileMaker file.
3. Query the stored ProofKitApps.HTML field's length vs. the source file's length (should match closely).
4. Diff a known substring from the source at a given character offset against a LIKE search on the stored field at that same logical position — content diverges.

Happy to share the exact source file / more detail if useful — this was hard to track down since it initially looked exactly like a JS engine compatibility issue (misleading SyntaxError at a shifting location) rather than payload corruption.

Questions

• Is there a known size limit or chunk size used when writing large payloads via deploy_html/PK_deploy_html?
• Is there a newer version of the FileMaker add-on that fixes a chunking/reassembly bug like this?
• Is there a recommended workaround for large single-file bundles (e.g., a different deployment path) in the meantime?