Skip to content

0.27.x

Release line: 0.27.0 and 0.27.1 were released on September 3, 2026; 0.27.2 was released on September 4. 0.27.3 is the upcoming release and includes the changes since 0.27.2, the latest published tag.

Comparison: These cumulative notes cover the 0.27 release line from v0.26.0 through the changes on main prepared for 0.27.3.

The 0.27 line turns the local dashboard process into a production-ready Stove Server that can be shared by teams and CI jobs. It adds PostgreSQL persistence, multi-replica event delivery, run metadata, configurable retention, administration tools, HTTP(S) ingestion, and a much more resilient dashboard. Version 0.27.2 completes the stove-cli to stove-server rebrand. Version 0.27.3 adds scoped CI diagnosis, links to exact evidence, persistent dashboard browsing state, and metadata-based cleanup.

Release map

Version Status Highlights
0.27.0 Released Shared server, PostgreSQL, multi-replica delivery, metadata, retention, administration, container image
0.27.1 Released HTTP(S) event ingestion, shared ingestion pipeline, OpenAPI and Swagger UI
0.27.2 Released Live-update reliability, scalable evidence UI, faceted metadata filters, Stove Server rebrand
0.27.3 Upcoming MCP diagnosis, exact evidence links, dashboard navigation and accessibility, metadata-based purge, stricter API validation

0.27.0 — a production-ready shared server

PostgreSQL joins SQLite

SQLite remains the zero-configuration default for a local server. A shared deployment can now use PostgreSQL:

stove --database-url 'postgresql://stove:secret@db.example/stove'

The PostgreSQL backend includes the complete dashboard data model, indexed metadata queries, versioned startup migrations, TLS by default, and the same REST, MCP, and dashboard behavior as SQLite.

Multiple Stove Server replicas can share one PostgreSQL database without session affinity. Event commits, deduplication, and the durable live-event record happen in one transaction. Per-run advisory locks preserve ordering, while PostgreSQL LISTEN/NOTIFY, outbox polling, and SSE Last-Event-ID replay keep every replica's browser clients current without Redis or another broker.

Dashboard events now carry a stable UUID and a per-run sequence number. A retry is idempotent, duplicate acknowledgements are explicit, and the server rejects conflicting reuse of an event identity. The protobuf additions are backward-compatible with clients that do not yet send ordering metadata.

Run metadata and shared-server discovery

DashboardSystemOptions accepts immutable string metadata for a run:

DashboardSystemOptions(
    appName = "checkout-api",
    metadata = mapOf(
        "team" to "checkout",
        "gitlab.project" to "commerce/checkout-api",
        "gitlab.pipeline_id" to (System.getenv("CI_PIPELINE_ID") ?: "local")
    )
)

Metadata is persisted with the run and exposed throughout the product:

  • The dashboard can select retained runs using metadata keys and values.
  • GET /api/v1/runs accepts an exact metadata subset.
  • MCP's stove_runs accepts the same dynamic string map, letting an agent select one pipeline or team before inspecting failures.
  • PostgreSQL stores metadata as indexed JSONB; no fixed server-side metadata schema is required.

Retention and administration

The server now retains the newest completed run per application by default. Configure another limit with --retention-runs-per-app, STOVE_RETENTION_RUNS_PER_APP, or the configuration file; 0 disables automatic pruning. Active runs are not removed automatically.

The new /admin workspace and REST endpoints provide:

  • backend and evidence statistics;
  • runtime retention changes, with immediate pruning;
  • purge preview by application and RFC 3339 cutoff;
  • exact run deletion, with active runs protected unless explicitly included;
  • full data clearing;
  • schema discovery and a native SQLite/PostgreSQL query explorer.

PostgreSQL persists the retention setting so every replica observes the same value. The browser asks for confirmation before mutations, but the explorer is deliberately a direct database tool and is not an authorization boundary.

Deployment and configuration

The server can be configured with command-line flags, STOVE_* environment variables, or TOML/JSON files. The precedence is CLI/environment, then configuration file, then built-in defaults. PostgreSQL credentials can be read from a mounted secret file through --database-url-file or STOVE_DATABASE_URL_FILE.

The 0.27 line also adds:

  • a non-root container image exposing HTTP/REST/MCP on 4040 and gRPC ingestion on 4041;
  • a local PostgreSQL Compose stack and just commands for development;
  • startup-safe migrations for concurrent replicas;
  • acceptance coverage for both storage backends and a 50,000-run PostgreSQL load test;
  • standalone release archives with PostgreSQL and OpenSSL client libraries bundled, avoiding a host libpq dependency.

See the Dashboard deployment guide for configuration, Docker, PostgreSQL, and Kubernetes examples.

Dashboard fixes and polish

  • Live run state keeps only the newest run for each application unless retention is configured to expose more history.
  • A newly observed run for another application no longer replaces the user's persisted application selection.
  • Mock warnings have a collapsible, easier-to-scan layout and improved dark-theme colors.
  • The application picker no longer shows a redundant run count.

0.27.1 — HTTP(S) ingestion and documented APIs

Choose gRPC or HTTP ingestion

Dashboard ingestion is now an explicit transport:

DashboardSystemOptions(
    appName = "checkout-api",
    ingestion = DashboardIngestion.Grpc(host = "stove.internal", port = 4041)
)

For an HTTPS-only ingress or API gateway that cannot forward gRPC, use HTTP:

DashboardSystemOptions(
    appName = "checkout-api",
    ingestion = DashboardIngestion.Http("https://stove-gateway.internal/stove")
)

HTTP sends the shared protobuf DashboardEvent to POST <baseUrl>/api/v1/events with application/x-protobuf and receives a protobuf EventAck. It has the same queueing, retry, rejection, auto-disable, validation, deduplication, persistence, and live-broadcast semantics as gRPC. A gateway path prefix is preserved.

Both adapters now call one ingestion use case, so acknowledgements and event handling cannot drift between transports.

OpenAPI and Swagger UI

The complete REST surface is available at:

  • /swagger-ui for interactive documentation;
  • /api-docs/openapi.json for the OpenAPI document.

The generated document is path-prefix safe and describes HTTP ingestion as binary protobuf rather than inventing a second JSON contract. The dashboard header links directly to the API documentation.

0.27.2 — reliable live updates and Stove Server branding

Live updates no longer freeze or lose terminal events

The server, emitter, and browser live-update paths were reworked together:

  • The JVM emitter no longer abandons queued terminal events after a fixed 30-second drain timeout. It waits for acknowledgement and periodically reports that draining is still in progress.
  • The durable SSE relay is the single publication path. Commit notifications reduce latency, high-water tracking is monotonic under concurrency, and a restarted server does not rebroadcast its retained history as new events.
  • SQLite writes no longer block the asynchronous runtime while waiting for the writer lock, and ingestion acknowledgements do not wait on the SSE read lane.
  • The browser validates SSE payloads, batches one frame of events into bounded cache updates, detects sequence gaps or queue overflow, and reconciles live data with in-flight REST responses by recency.
  • Reconnects and missed-event conditions invalidate the affected queries, while disconnected dashboards fall back to polling.

These changes fix dashboards that could stop updating under concurrent ingestion, stale requests that could overwrite newer live state, duplicate evidence during reconciliation, and shutdowns that could omit the final run events.

Large evidence sets stay responsive

The test detail UI has been split into focused evidence, mock-journal, trace, snapshot, and flow components. Evidence, mock exchanges, and trace spans use virtualized lists once they become large. SSE batches are reduced to one cache write per query, trace layout runs in a worker, and snapshot JSON parsing/search starts only when the explorer is opened.

The refreshed workbench also adds clearer issue filters, / search focus, dedicated inspectors and dialogs, snapshot search and metrics, improved keyboard focus, and more useful empty states.

Faceted metadata filtering

The run sidebar now derives metadata facets from retained runs. Users can select several values without typing them manually:

  • values within one key are combined with OR;
  • different keys are combined with AND;
  • value counts, active-filter chips, matching-run counts, and one-click clearing stay visible.

stove-cli is now stove-server

The project name now reflects what the process does:

  • source moved from tools/stove-cli to server/stove-server;
  • the Rust package, workflows, UI copy, docs, and skills use Stove Server;
  • container builds from 0.27.2 publish as ghcr.io/trendyol/stove-server instead of ghcr.io/trendyol/stove-cli.

The executable, Homebrew formula, and command remain stove; existing shell commands do not change. The 0.27.0 and 0.27.1 images were published before the rename and therefore remain under ghcr.io/trendyol/stove-cli.

0.27.3 — scoped diagnosis and evidence navigation

Diagnose one CI execution through MCP

The new stove_diagnose tool investigates an exact run, selected by run_id or application plus CI metadata. It returns ranked findings for failed tests, including exception locations, mock near misses, assertion differences, and diagnostic fields in recorded payloads and snapshots.

Each result includes bounded timeline and trace context, direct evidence citations, omission counts, and follow-up tool calls. Failed tests are paginated, and continuation calls preserve the selected run. If several executions match, the tool returns candidates instead of silently selecting the newest run. Active runs and incomplete evidence are identified explicitly.

MCP evidence responses are more compact and consistent:

  • stove_trace offers critical_path, exceptions, and tree views.
  • Snapshot JSON pointers resolve against the complete redacted state before preview limits are applied.
  • Responses expose omitted-item counts and structured results alongside compact JSON text.
  • Invalid arguments and missing evidence return actionable tool errors.

Findings describe recorded evidence, not proven root causes. See the MCP guide for selectors, budgets, and investigation examples.

Open the exact evidence cited in a report

MCP results now link directly to a run, test, error, or individual evidence record. The dashboard opens the matching tab and inspector, with options to expand nearby context or show the full test. Links can also be copied from the dashboard.

A cited retry stays on that exact attempt even if a later retry passed. Snapshot links can select a JSON value, and evidence without a test attribution opens at run scope. Missing, expired, or incorrectly scoped records show an unavailable state rather than unrelated evidence.

Configure the address used in shared links with:

stove --public-url https://stove.example/observe

The equivalent settings are STOVE_PUBLIC_URL and config-file public_url. UI assets, REST, SSE, and MCP support the configured path prefix, including gateways that preserve or strip it. Evidence links remain usable only while their records are retained.

Keep your place while investigating

  • Switching tabs preserves evidence searches, filters, payload views, collapsed trace branches, scroll positions, and intentionally closed inspectors.
  • Ordinary dashboard selections stay in the current workspace; explicit evidence links retain their exact targets, and browser back/forward restores navigation.
  • Live arrivals and temporary request failures no longer displace the selected evidence or discard the selected application, run, or test.
  • Virtual-list scrolling is fixed, and inserting earlier records preserves the visible scroll anchor.
  • Phone layouts provide a focused drill-down flow with Back restoring the previous list position. Desktop navigation adds a resizable test navigator, keyboard tab navigation, clearer focus handling, and accessible inspector controls.
  • Assertion comparisons are easier to inspect, expected HTTP errors keep their successful status, and failed tests take precedence over running siblings in group summaries. OpenTelemetry UNSET span statuses remain distinct from success.

Preview cleanup by run metadata

The admin workspace can now preview purges for an application's metadata values, alongside the existing cutoff and running-run controls. Select multiple values within a key with OR, and combine different keys with AND. Searchable metadata lists preserve selections while filtering.

POST /api/v1/admin/purge/preview accepts the same metadata map of string arrays and requires app_name when metadata is supplied. SQLite and PostgreSQL apply the same criteria; deletion uses the exact run IDs returned by the preview. Changing criteria invalidates the old preview, and switching applications clears metadata selections. Running runs remain protected unless explicitly included.

Retention forms and database queries also preserve local edits during refreshes, surface command errors, and discard obsolete responses. Purging data invalidates the affected dashboard caches.

Stricter contracts and validation

The dashboard's REST and live-event types are generated from the server's OpenAPI contract, with CI checking for drift. Runtime validation rejects malformed responses and invalid event statuses; invalid ingestion does not persist evidence or publish live events. Stored malformed JSON, unknown statuses, and empty assertion IDs now produce explicit errors instead of fabricated defaults.

Development snapshots and build tooling

Maven snapshot publishing now also publishes a matching versioned Stove Server container and updates ghcr.io/trendyol/stove-server:snapshot. Stable releases continue to use :latest; snapshot builds do not move that tag.

Contributor setup now provides shared just commands, mise configuration, and Lefthook checks scoped to the changed projects. CI uses the Gradle wrapper and revised build caches. The dashboard declares TypeScript ~7.0.2; its OpenAPI generator retains TypeScript 5 as a tooling peer dependency for compiler-API compatibility.

Migration guide from 0.26.0

1. Recreate the dashboard database

The storage rewrite adopts backend-specific Refinery migrations and intentionally does not import databases whose migration history was recorded in the old schema_migrations table.

For the default SQLite database, start once with:

stove --fresh-start

This backs up the existing file before creating the new database. If you use a custom SQLite path, pass the same --db value. Recreate an existing PostgreSQL database or schema before pointing 0.27.x at it. Export anything you must retain before either operation.

2. Replace cliHost and cliPort

0.27.1 replaces the dashboard-specific host and port fields with the transport model.

Before:

DashboardSystemOptions(
    appName = "checkout-api",
    cliHost = "stove.internal",
    cliPort = 4041
)

After:

DashboardSystemOptions(
    appName = "checkout-api",
    ingestion = DashboardIngestion.Grpc(
        host = "stove.internal",
        port = 4041
    )
)

Calls that only pass appName keep the same behavior because local gRPC on port 4041 remains the default. Recompile code that constructs DashboardSystemOptions or DashboardEmitter directly.

3. Update the container name from 0.27.2 onward

When moving from the 0.27.0/0.27.1 image to a later 0.27.x image, change:

ghcr.io/trendyol/stove-cli:<version>

to:

ghcr.io/trendyol/stove-server:<version>

Ports, volumes, configuration keys, and the stove entrypoint are unchanged.

4. Update REST metadata clients

The Stove Server rebrand renames the server-version field in the REST metadata response. Update clients that read:

stove_cli_version

to use:

stove_server_version

5. Review stricter validation when upgrading to 0.27.3

Correct or remove corrupt stored records if reads report malformed structured fields, unknown statuses, or empty assertion IDs. These records are no longer silently coerced into defaults. Valid existing 0.27.x databases use the normal startup migrations; the database recreation above applies to upgrades from the old 0.26.0 migration history.

Custom MCP clients should handle isError: true, respect the advertised argument ranges, and inspect omission counts before treating evidence as complete. Use exact run selectors with stove_diagnose and follow the returned continuation calls when failures span several pages.

6. Keep shared deployments private

The dashboard, REST API, admin/database explorer, MCP endpoint, and both ingestion ports intentionally have no built-in authentication or authorization. Bind them only to a trusted network or place an authenticated private gateway in front of them.

Dependency and build updates

The 0.27 line includes the following dependency updates, comparing v0.26.0 with the versions prepared for 0.27.3:

Area From To
Kotlin 2.4.10 2.4.20
Exposed 1.4.0 1.5.0
MongoDB Java driver 5.10.0 5.11.0
Elasticsearch clients 9.5.2 9.5.3
Quarkus 3.39.0 3.39.3
Micronaut 5.1.12 5.2.0
Micronaut Platform 5.1.1 5.1.4
Micronaut Data R2DBC 5.1.2 5.1.4
SnakeYAML 2.6 2.7
Mordant 3.0.2 3.1.0
Flyway 13.3.0 13.6.0
H2 2.4.240 2.5.250
SQL Server JDBC 13.4.0.jre11 13.6.0.jre11
SLF4J 2.0.18 2.0.19
Spotless 8.10.0 8.10.2
Wire 6.4.6 7.0.1
gRPC Java 1.83.1 1.84.0
Protobuf 4.36.0 4.36.1
KSP 2.3.11 2.3.12
Kotlin binary compatibility validator 0.18.1 0.18.2
OpenTelemetry semantic conventions 1.43.0 1.44.0
Byte Buddy 1.18.12 1.18.13
Lombok 1.18.46 1.18.48
Go OpenTelemetry 1.45.0 1.46.0
Go OTel HTTP instrumentation 0.70.0 0.71.0
Go gRPC 1.83.1 1.83.2
Go gRPC Gateway 2.29.0 2.30.0
TanStack React Query 5.102.2 5.102.8
React / React DOM 19.2.8 19.3.0
Vite 8.2.2 8.3.0

Routine lockfile and transitive updates are included as well. CI moved to actions/setup-java v6 and the current major versions of Docker login, metadata, Buildx, and build/push actions. Container builds now persist compiler caches, and workflow names follow the Stove Server branding.

Full comparisons