Skip to content

No sanctioned post-deploy verification step — apps ship frontends against an unconfirmed backend #237

Description

@hfurkanbozkurt

Which package(s) are affected?

@aws-blocks/core, @aws-blocks/create-blocks-app (deploy/sandbox scripts)

Describe the problem

After npm run deploy / npm run sandbox there is no first-class, documented way to verify the deployed backend actually serves traffic (config injected, handler importable, JSON-RPC reachable) before the frontend is pointed at it. A deploy can succeed while the backend is non-functional (bad handler import, or the config.json placeholder still served - see #173), with no server-side error at deploy time.

Impact

Consumers (and AI coding agents) ship frontends against an unverified backend and discover breakage only via end-to-end UI failure. No smoke check fails fast at deploy time.

Proposed fix

Add a sanctioned post-deploy verification step (e.g. npm run deploy -- --verify or blocks verify <url>) that: (1) fetches /.blocks-sandbox/config.json and asserts a real apiUrl (not {"_placeholder":true}), (2) issues a trivial JSON-RPC/health probe against apiUrl, (3) exits non-zero on failure. Document it in the deploy flow.

Related

#173 (stale placeholder config served post-deploy).

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pending-maintainer-responseWaiting on a response from the maintainerspending-triageIssue is pending triage by the maintainers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions