Skip to content

feat(testserver): build the testing server as a WASI module - #3443

Open
josephschorr wants to merge 1 commit into
authzed:mainfrom
josephschorr:wasi-evaluator
Open

josephschorr wants to merge 1 commit into
authzed:mainfrom
josephschorr:wasi-evaluator

Conversation

@josephschorr

Copy link
Copy Markdown
Member

Summary

Test doubles in our non-Go client libraries can't evaluate schemas, so tests of real permission logic either hand-write resolvers that drift from the schema or need a running SpiceDB. This PR builds the testing server (the one behind serve-testing) as a WASI module that any language with a WebAssembly runtime can embed, so doubles can answer checks, lookups and writes with SpiceDB itself.

  • WASI module (pkg/cmd/testserver/wasi): a wasip1 reactor exposing a small bytes-in, bytes-out ABI over the public authzed.api.v1 protobufs. It serves PermissionsService, SchemaService and ExperimentalService, with an isolated datastore per session and the same configuration, limits and errors as serve-testing. The README documents the ABI, and a Python (wasmtime) example host is included.
  • In-process server (pkg/cmd/testserver/inprocess): a lean server over an in-memory connection that backs the module, also usable directly from Go. It avoids pkg/cmd/server, which keeps the datastore drivers and telemetry exporters out of the build.
  • Shared configuration (internal/testingserver): the services, limits and dispatcher setup now shared by serve-testing and the in-process server, so the two can't drift.
  • Build and release: mage build:wasi produces dist/spicedb-testserver.wasm, and the release workflow now attaches it alongside the existing WASM bundle.

Testing

  • A parity test runs the same calls against the in-process server and serve-testing, and requires identical responses and errors.
  • mage test:wasi hosts the built module in wazero and exercises schema writes, checks, lookups, errors and sessions. It runs in the existing WASM CI job.
  • The Python example's conformance script runs a fixture against the module and against a real spicedb serve-testing. It covers union, intersection, exclusion, arrows, wildcards, nested groups, caveats, expiration, depth limits and error cases, and all results were identical.

@josephschorr
josephschorr requested a review from a team as a code owner October 29, 2026 22:32
@github-actions github-actions Bot added area/cli Affects the command line area/dependencies Affects dependencies area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) labels Oct 29, 2026
@codecov

codecov Bot commented Oct 29, 2026 •

Copy link
Copy Markdown

Adds a WASI (wasip1) reactor build of the testing server run by
`serve-testing`, so test doubles in client libraries for any language can
evaluate checks, lookups and writes with SpiceDB itself instead of
reimplementing schema evaluation.

The module serves the authzed.api.v1 PermissionsService, SchemaService and
ExperimentalService through a small bytes-in, bytes-out ABI over the public
protobufs, with an isolated datastore per session and the same configuration,
limits and errors as `serve-testing`. It is built by `mage build:wasi` and
attached to releases.

The configuration shared with `serve-testing` moves to
internal/testingserver, and a lean in-process server in
pkg/cmd/testserver/inprocess backs the module without pulling in the
datastore drivers. A parity test compares it with `serve-testing`, and the
module itself is tested under wazero in CI.

This branch has not been deployed

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

Labels

area/cli Affects the command line area/dependencies Affects dependencies area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant