Uh oh!
There was an error while loading. Please reload this page.
Add SurrealDB as a community world - #3314
Conversation
Squashed and rebased onto main to resolve conflicts with the generic docker community-world CI: the dedicated surrealdb service steps from the original commits are replaced by the manifest-driven docker service type, with a new optional `args` field so the service definition can pass the `start` subcommand (and credentials) to the SurrealDB image. Signed-off-by: sepcnt <30561671+sepcnt@users.noreply.github.com> Signed-off-by: Pranay Prakash <pranay.gp@gmail.com> Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: ae4178a The changes in this PR will be included in the next version bump. This PR includes changesets to release 0 packagesWhen changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📊 Workflow Benchmarkscommit Backend:
📈 STSO distribution vs main (inline / queue-hop histograms)1020 steps (inline) Cumulative STSO time: main 152131ms → this run 117244ms (Δ -34887ms, -23%) ℹ️ Metric definitions & methodologyThe collapsed STSO distribution section above buckets every step gap of the sequential-steps run (not a sampled window), split by whether the step ending the gap ran inline — in the same warm process as the step before it, so the gap is pure framework overhead — or after a queue-hop — the first step of a fresh process, which pays queue dispatch, client reinit and event-log replay. Bars overlay the two runs: Best/P75/P90/P99 deltas compare against the most recent benchmark run on Metrics — TTFS: time to first step body (in-deployment start() → first step body, deployment clocks) · STSO: step-to-step overhead (gap between consecutive step bodies) · WO: workflow overhead (whole-run time outside step bodies, in-deployment anchored) · SL: stream latency (in-deployment write → read propagation, readAt - writtenAt) · SO: stream overhead (end-to-end write+consume time beyond the modelled generation window) Scenarios — step: one trivial no-op step, no stream; no hooks, so the run stays in turbo mode (in-process fast path) · stream: one streaming step; no hooks, so the run stays in turbo mode (in-process fast path) · hook + stream: registers a hook before one step, which exits turbo mode (dispatch path) · 1020 steps: 1020 trivial sequential steps; STSO is measured between consecutive steps in the given step ranges, and WO is the whole-run overhead outside step bodies · stream latency: parallel reader/writer steps on a dedicated stream; SL is the in-deployment write->read propagation (readAt - writtenAt) · stream overhead (text): writer streams 300 variable-length text token deltas paced at 100/s for 3s (a haiku-size LLM's token throughput) while a parallel reader drains the whole stream; SO is the end-to-end write+consume time beyond the 3s generation window (overhead/backpressure) · stream overhead (structured): same workload as stream overhead (text), but each delta is an AI-SDK-style structured object ({ type: 'text-delta', id, text }) instead of a raw string, so the SO gap vs the text scenario is the added serialization cost 🔴 marks a percentile over its target (within target is left unmarked). Targets (p75/p90/p99, ms) — TTFS 200/300/600 · SL 50/60/125 · SO 250/500/1000 All metrics are measured from deployment-side timestamps only. Runs are triggered by an in-deployment route that stamps the anchor ( Cold starts are kept in the numbers on purpose — they are part of real bursty-workload latency. The workbench deployment cold-starts the |
🧪 E2E Test Results❌ Some tests failed ❌ Failed E2E Tests💻 Local Development (1 failed)astro-stable (1 failed):
E2E Test SummarySummary
Details by Category✅ ▲ Vercel Production
❌ 💻 Local Development
✅ 📦 Local Production
✅ 🐘 Local Postgres
✅ 🪟 Windows
✅ 📋 Other
✅ vercel-multi-region
|
There was a problem hiding this comment.
Pull request overview
Adds a SurrealDB-backed “community world” entry to the repo’s worlds-manifest.json, and updates the community-world E2E workflow’s generic Docker service runner to support passing explicit command/argument lists to an image’s entrypoint (needed by the surrealdb/surrealdb:v3 image).
Changes:
- Add
surrealdbcommunity world metadata (env + service container + setup command) toworlds-manifest.json. - Extend
.github/workflows/e2e-community-world.ymlgenericdockerservice startup logic to append optional manifest-providedargsafter the image name. - Add an empty-frontmatter changeset documenting the manifest + workflow update without bumping packages.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
worlds-manifest.json | Registers the SurrealDB community world and declares its service container + required env/setup for CI execution. |
.github/workflows/e2e-community-world.yml | Lets manifest-defined docker services pass command args to container entrypoints (required for SurrealDB v3 startup). |
.changeset/add-surrealdb-world.md | Records the change while intentionally producing no package releases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
pranaygp
commented
Aug 4, 2026
original PR merged |
Adopts #1579 by @sepcnt so CI can run — fork PRs never receive repo secrets, so the required
e2e-vercel-prodlane can structurally never pass there. The commit is authored by @sepcnt with their DCO sign-off preserved.What this adds
worlds-manifest.json: SurrealDB community world entry (workflow-world-surrealdb), with its container declared in the manifest'sservicesarray (genericdockerservice type)e2e-community-world.yml: optionalargssupport in the generic docker service runner — thesurrealdb/surrealdb:v3image hasEntrypoint: ["/surreal"]and no default command, so a service definition must be able to pass thestartsubcommand and flagsThe community-world e2e lane remains disabled (
if: false) until community worlds implement theworld.streams.*interface, so the SurrealDB job won't execute yet either way.Closes#1579
🤖 Generated with Claude Code