Verify Bindings

Help improve the bindings by trying them in your application. Share a small reproduction when something fails, a workaround that helps, or a working example others can run.

Choose the check for your change

The integration test guide explains how to run local and hosted tests. The suite catalog lists implemented checks and planned coverage. Compilation checks types and emitted calls; hosted tests exercise the service itself.

Some imported types have known limitations: F# cannot directly subclass Container, AIChatAgent, or Think. The Containers and Chat agents pages describe the available integration patterns.

Start with one behavior

Choose a small operation: a container request after startup, a Sandbox command with a failing exit code, a workspace file read after wake-up, an Artifacts fork and push, or MCP discovery after reconnect. State the expected result before running it.

Follow Packages to prepare package consumption, or Local Build when testing changes to generated source. From the repository root, compile the relevant site example project. For example:

dotnet build site/examples/Agents/Agents.fsproj --nologo
dotnet build site/examples/Compute/Compute.fsproj --nologo
dotnet build site/examples/Services/Services.fsproj --nologo

Run these builds sequentially. They restore 0.1.* packages by default. For contributor source builds, add -c Release -p:CloudEdgeUseSource=true. Agents contains the SDK and tool examples, Compute contains workspace and Sandbox examples, and Services contains the Containers consumer.

The documentation excerpt check is separate:

dotnet run --project tools/NuGetRelease -- snippets

It compares the site's F# snippets with source files under site/examples; it does not compile or execute them. After running the package consumer checks, compare the displayed JavaScript with their Fable output:

dotnet run --project tools/NuGetRelease -- snippets --js-root artifacts/nuget-release/0.1.0/consumers-candidate/js

For example, emit the Agents consumer with the repository's pinned Fable tool:

dotnet fable site/examples/Agents/Agents.fsproj --outDir artifacts/site-examples/Agents

Use the matching project and output directory for Compute, Services, or Storage. Inspect the relevant generated file before moving on to runtime checks.

Exercise the runtime boundary

Run the smallest consumer in the environment required by the capability. Record the Fable and npm versions, compatibility date and flags, binding configuration, and whether the test used Node, a local Worker runtime, or Cloudflare. Inspect the emitted import and call when the failure crosses from F# into JavaScript.

Where practical, compare with an equivalent JavaScript or TypeScript call against the same pinned upstream package and configuration. That helps distinguish a binding defect from an upstream behavior or setup issue. An incomplete comparison is still worth reporting; say what you could and could not reproduce.

For hosted lifecycle tests, record startup and readiness, the operation's result, recovery if exercised, and resource deletion. Confirm cleanup separately from the main assertion. Keep tokens and private application data out of published fixtures and logs.

Share a result

Use the binding report form for a defect, missing API, or successful verification result. Include:

• Repository commit, binding library, upstream npm package and version, and the affected symbol.
• Minimal F# source, relevant configuration, and commands to reproduce.
• Expected behavior and actual output, including errors or assertions.
• Runtime environment and the checks actually performed.
• Any equivalent upstream example, workaround, or cleanup result.

Check existing issues and the upstream issue notes for related work. Include a regression test with a fix so the behavior stays covered.