Upload index.html with the assets, and keep error bodies that aren't JSON

[netanelgilad]

Note

Description

A static site deploy used to send the built index.html as a file part on the finalize request. Cloudflare's managed WAF inspects that body, and one app's markup contained a documentation comment with a backticked shell command — so every publish was answered 403 at the edge, 54/54 over a week, before the request ever reached the backend. This PR routes the entry point through the same presigned S3 PUT path as every other asset, so finalize carries no user-authored content at all, and separately makes ApiError.fromHttpError keep a non-JSON error body instead of discarding it — which is what made the original failure take a week to diagnose.

Related Issue

Requires the server-side counterpart base44-dev/apper#25992. Without it the server leaves index_html_staged unset and this client behaves exactly as before.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Other (please describe):

Changes Made

feat(site): upload index.html with the assets instead of at finalize

• CreateDeploymentResponseSchema reads a new index_html_staged field, .optional().default(false) — an older server leaves it unset and the client keeps sending the bytes, so the release needs no coordination with a backend deploy in either direction.
• FinalizePayload becomes an exported discriminated union (worker / static-inline / static-staged). The previous "indexHtml" in payload shape could not express "send nothing", and Record<string, never> types loosely inside a union.
• deployment.ts splits the old readIndexHtml into requireStaticEntryPoint (validation, still run before create so a build that cannot be completed fails before any upload work) and resolveStaticCompletion (reads the bytes only when finalize will actually carry them).
• index.html itself goes up through the existing uploadPresignedAsset path with no changes — the server signs it to a staging key and copies it into the build at finalize; the client does not need to know the key.

fix(errors): keep an error response body that is not JSON

• ApiError.fromHttpError previously fell back to ky's message, which names only the status and URL, so an opaque 403 or 502 read identically whoever emitted it.
• Adds readResponseText(): reads a clone() so the caller's body stays unconsumed, never throws (it runs on a path already reporting a failure), and truncates at 500 chars so an HTML error page cannot flood a log.
• When the body is empty, the message reports the content-type instead — an empty body is itself a fingerprint of the layer that answered.

Testing

• I have tested these changes locally
• I have added/updated tests as needed
• All tests pass (npm test)

New coverage:

• static_site_deployments.spec.ts — a new "index.html staged through the presigned PUTs" suite asserting the entry point is PUT with the other assets (unsigned, byte-identical to the fixture) and that finalizeRequests[0] is [], i.e. no user HTML in a request body of ours. The existing legacy-path cases stay as backward-compat coverage.
• errors.spec.ts — three cases: an HTML body naming its emitter, an empty body reporting its content type, and truncation of a 2000-char body. One existing assertion changed: expect(apiError.responseBody).toBeUndefined() on a non-JSON body was pinning the exact defect.
• TestAPIServer.ts — the create-response type gains the optional index_html_staged flag.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (if applicable)
• My changes generate no new warnings
• I have updated docs/ (AGENTS.md) if I made architectural changes

Additional Notes

Why "all tests pass" is unchecked: the reported run is 843 passed with 2 failures in dev.spec.ts, which reproduce identically on the untouched baseline (confirmed by stashing and re-running). bun run typecheck and bun run lint are clean.

Reproduction (differential probe against production on a non-existent route, so the trigger is the body and not the path):

body	result
benign HTML	404 from FastAPI — reached origin
the app's index.html	403, server: cloudflare, <title>Blocked</title>
Run `curl -s https://api.example.com/health` to check.	403
curl -s https://x.com | grep (no backtick)	ok

No retry could help — the bytes were the trigger, and nothing about the app was wrong.

Not fixed here: the full-stack arm still POSTs worker modules through finalize, and a JSDoc comment or help string containing a backticked command plus a URL in a .js module part hits the same WAF rule (verified against production). A WAF exception scoped to the finalize path is still wanted — it is the only thing covering that arm, and it unblocks the affected app today rather than after a release plus sandbox-image pickup.

---

_{🤖 Generated by Claude | 2026-09-23 04:58 UTC | 845faaa}

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/cli@0.1.16-pr.637.845faaa

Prefer not to change any import paths? Install using npm alias so your code still imports base44:

npm i "base44@npm:@base44-preview/cli@0.1.16-pr.637.845faaa"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "base44": "npm:@base44-preview/cli@0.1.16-pr.637.845faaa"
  }
}

• 📦 Preview Package: @base44-preview/cli@0.1.16-pr.637.845faaa
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}