0.39.1-M1 is the first milestone of 0.39 — the largest change Orbital has had. It has been in development since April, and it changes the shape of the product in a few significant ways.

The headline is workspaces: a single Orbital instance can now run many independent schemas, each with its own projects, its own compiled schema, its own connections and its own query context. Everything downstream of that — auth, secrets, search, history, caching, the language server — was reworked to be workspace-aware.

Alongside that: a secrets manager with five backends, a data validation framework, Copilot (chat-driven querying and schema building), an MCP server so external agents can query your data mesh, and a new code editor that edits whole projects rather than single queries.

Two features we announced over the summer also ship here for the first time: collection options (limit, offset, orderBy, uniqueBy on any query, pushed down to the source where it can take them), and @DeleteOperation / @SqlQuery for the database connectors.

As a milestone, 0.39.1-M1 is for early adopters and teams who want to test ahead of the full 0.39 release. Expect rough edges, and tell us about them.

​Breaking changes

​Orbital now requires a licenseBreaking change

Orbital checks for a license.json on startup. When you first sign in, Orbital contacts the license server at https://account.orbitalhq.app, downloads a free license and installs it. In most environments this needs no setup.

If no license is found, Orbital issues a short-lived fallback license so the server still starts — but that fallback only lasts 30 minutes, after which the UI shows a blocking overlay.

Orbital searches these paths in order, and the first valid license wins:

1. --vyne.license.path (if set)
2. ${vyne.app.data.path}/license.json — by default ./orbital_data/license.json
3. ~/.orbital/license.json
4. /opt/var/orbital/license/license.json

For air-gapped deployments that can’t reach the license server, Orbital supports an air-gapped mode that disables usage reporting. Get in touch if you need it.

See configuring your license for the full detail.

One improvement worth calling out: an expired license no longer terminates the JVM. The old LicenseMonitor called exitProcess(0) on expiry. That’s gone — expiry now surfaces in the UI and is governed by the license policy instead of killing the process.

​The workspaces-enabled toggle is replaced by workspace-modeBreaking change

The boolean toggle is gone, replaced by a three-state enum:

vyne:  toggles:    workspace-mode: None    # None | Workspace | OrgAndWorkspace

If you were setting workspacesEnabled: true, that key is now ignored and you will silently fall back to None. Set workspace-mode instead.

​Query history tables gain non-null orgId and workspace_slug columnsBreaking change

A Flyway migration adds a workspace_slug column across eight history tables, adds orgId to query_error_event and trace_event, backfills both with default, and enforces NOT NULL. Indexes on (orgId, workspace_slug) are created alongside.

The migration runs automatically. On instances with a large query history, the SET NOT NULL statements take a table lock, so budget for some downtime on the first boot after upgrading.

The same migration drops the Postgres row-level-security policies on those tables. RLS was keyed on current_user, which never worked with a shared connection pool. Org and workspace isolation is now enforced in the application layer via org-membership checks and explicit orgId / workspace_slug filters on every query.

Rows written before this milestone cannot be attributed to a workspace — they were never stamped — so they stay as default/default.

​The legacy Jet pipeline server has been removedBreaking changeRemoved

pipelines/pipeline-jet is gone from the build, along with the pipeline transports that only it used (S3, SQS, Cask, file-watcher, HTTP listener, JDBC, Kafka, Redshift, logging sink, polling query input) and the transform stage.

This is the standalone pipeline runner, which has been unmaintained and undocumented for a long time. Streaming queries are unaffected — stream { } queries run through pipelines/stream-engine, which stays.

​H2 is no longer a shipped JDBC driverBreaking changeRemoved

H2DatabaseSupport has moved to test sources. The drivers shipped to end users are now Postgres, MSSQL, Oracle, Redshift, Snowflake and Databricks. If you had an H2 connection defined in connections.conf, it will fail to resolve.

​Spring Boot 4 and Jackson 3Breaking change

Orbital is built on Spring Boot 4.0 and Jackson 3. If you write custom Orbital extensions — custom taxi functions, custom connectors, anything compiled against Orbital’s jars — you will need to migrate. The main things that bite:

• Jackson 2 → 3: the mapper and builder are immutable, and several APIs were renamed. The annotation package is still com.fasterxml.
• Spring 7 / Security 7 JSpecify nullability, and : Any generic bounds in Kotlin.
• The Spring Boot 4 modular auto-config split (spring-boot-health, -jdbc, -hibernate, -mongodb, and the matching test slices).
• Testcontainers 1.x → 2.x, if your tests use it.

​Numeric comparison is now type- and scale-insensitiveBreaking changeFixed

Comparisons between numbers of different JVM types now coerce both sides to BigDecimal and compare with compareTo. Two consequences:

• Cross-type numeric comparisons work. Previously only a narrow set of pairings (such as Int vs BigDecimal) compared correctly; others silently failed.
• Equal and NotEqual are now scale-insensitive. 2.50 == 2.5 is now true where it was previously false, because BigDecimal.equals treats different scales as different values.

Taxi’s Long is backed by BigInteger, which previously had no branch in the arithmetic calculator at all and errored with “Unsupported number type”. Long arithmetic now works, and division on Long truncates — the same semantics as Int.

​The right() function now reads from the rightBreaking changeFixed

right(input, n) was returning characters counted from the left of the string. It now returns the last n characters, as the name and documentation always said. If you worked around the old behaviour, remove the workaround.

​Operation parameters are no longer matched to raw primitives by typeBreaking changeFixed

Given operation confirm(OrderId, note : String) and an OrderId in context, the old code would bind the OrderId’s value to note — because everything is assignable to String, so a raw primitive parameter matched whatever value happened to be nearby.

Parameters typed as raw primitives (String, Int, …) or Any are now populated only from an exact type match already in context — never an inherited match, never a graph query. Otherwise they resolve to null and normal nullability handling applies.

A default declared in the signature is unaffected, because it names the parameter it belongs to rather than being matched to it. That remains the supported way to populate a raw primitive.

If a schema was relying on the old behaviour, the operation will now be invoked with a null (or not invoked at all, if the parameter is required). Give the parameter a semantic type, or a default.

​Query responses honour the Accept headerBreaking changeFixed

HTTP query responses now follow standard content negotiation, in this order:

1. An explicit, specific Accept header wins.
2. Otherwise the response type’s declared format (@Xml, @Csv) is used.
3. Otherwise JSON.

Previously the model’s declared format always won, so a model annotated @Xml requested with Accept: application/json still came back as XML. If you have a client relying on that — sending an Accept header it didn’t mean and getting the model’s format regardless — it will now get what it asked for.

An absent Accept header is treated as “no preference” rather than being forced to JSON, so it defers to the model’s declared format. This applies uniformly to the /api/taxiql endpoints and to routed saved queries. Streaming responses (SSE and WebSocket) negotiate separately and are unchanged.

​API routes are workspace-prefixed when workspace mode is enabledBreaking change

In Workspace or OrgAndWorkspace mode, all workspace-scoped APIs move under /api/{orgId}/{workspaceId}/..., and published query endpoints move to /api/{orgId}/{workspaceId}/q/....

In None mode — the default — legacy routes such as /api/schema/types and /api/q/myQuery continue to work exactly as before. This includes the anonymous-access security matcher, which now picks the pattern matching the active mode.

​Smaller breaksBreaking change

• The auth-token listing API changed shape. GET /tokens returned a flattened Map<ServiceName, List<AuthScheme>>. It now returns a row-shaped listing that preserves the package each entry came from, plus a sibling field carrying per-package parse errors.
• Git credentials in workspace.conf are now secret references. Inline GitCredentials / GitSshAuth are replaced by a GitAuthentication reference that points at a secret name resolved through the workspace’s secrets manager at fetch time.
• SOAP responses are parsed by JAXB element names. Responses are read using @XmlElement metadata and field access rather than by introspecting CXF’s generated Java getters. This fixes acronym and casing mangling (getSISOCode was becoming SISOCode rather than sISOCode), but if you had types hand-shaped to match the old mangled names, they now need to match the WSDL names.
• UI routes renamed, with redirects in place: /stubs → /local-environment, /catalog/diagram → /mesh, /workspace → /workspaces. The old query editor at /query/editor is replaced by /code-editor.
• New privileges. LIST_SECRETS and EDIT_SECRETS were added and are granted to the admin and platform manager roles in the bundled default role definitions. Deployments that already have a roles.conf on disk will not pick these up automatically — Orbital only writes the defaults when the file is absent. Add them by hand if you want the secrets UI available to existing roles.

​Workspaces and organisationsNew

A workspace is a named context that compiles to a schema. Everything schema-driven in Orbital — queries, streams, published endpoints, the catalog, the search index — operates within one.

Typical uses:

• Team isolation — each team owns a workspace with its own services and types.
• Environment separation — production, staging and development in one cluster.
• Safe experimentation — test a new version of a service in a workspace without touching the others.

An organisation is the tenant above that. A cluster serves one or more organisations; on-prem deployments typically have one, and a default org is created on first boot if none exists.

​Turning it on

vyne:  toggles:    workspace-mode: OrgAndWorkspace

When enabled, a combined org-and-workspace selector appears in the header. Collapsed, it shows the active workspace above the active organisation; expanded, it lists the workspaces in the org, with a nested Switch organisation submenu and management actions. In Workspace mode the org half is hidden.

Every page — catalog, code editor, projects, activity — is scoped to the active workspace, and the URL reflects it.

​Where workspace config lives

Two things need storing: which orgs and workspaces exist, and what projects make up each workspace. Both are configured under vyne.orgs:

vyne:  orgs:    store: FILE                 # FILE | IN_MEMORY | DATABASE    config-path: ./orbital_data

The file backend reads an organisations.conf from config-path, with one workspace.conf per workspace underneath:

orbital_data/  organisations.conf  workspaces/    acme-bank/      production/workspace.conf      analytics/workspace.conf

The database backend stores the same HOCON content as text blobs in org_config, workspace_config_entry and workspace_config, using Spring Data repositories over Orbital’s existing datasource. Because the stored content is byte-identical to the file format, you can move between backends without transforming anything.

Workspace config also materialises back to disk on boot, so a cloud deployment with a populated database and a fresh disk rehydrates correctly. The file backend leaves hand-edited content alone.

​What became workspace-aware

The bulk of the work in 0.39 was making everything downstream of the schema respect workspace boundaries. Things that used to be global singletons and are now per-workspace:

• Connections and invokers. Every connection-based invoker (JDBC, Kafka, MongoDB, AWS, Azure, Hazelcast, SOAP, HTTP) is built per workspace through an InvokerFactory, from that workspace’s own connection registry.
• services.conf and auth.conf. Service discovery and outbound auth resolve through per-workspace registries, so HOCON substitution sees that workspace’s own environment variables. Previously a single global registry meant auth.conf files discovered through a workspace’s project additionalSources were silently ignored, and outbound HTTP calls went out unauthenticated.
• Hazelcast state. Operation caches, state stores and stream topics are all namespaced by workspace, so results can’t leak across boundaries.
• The search index. Lucene indices are per workspace, stored under {basePath}/{orgId}/{workspaceId}/, rebuilt only for the workspace whose schema changed.
• Query history. Every history table is stamped and filtered by org and workspace.
• The language server. LSP sessions resolve the workspace’s live schema, and schema edits are delivered to the sessions bound to that workspace.
• WebSocket streams. Schema notifications, query status, stream results and stub updates all reconnect when you switch workspace, and are filtered to the workspace you’re connected to.
• Query routes, scheduled queries and persistent streams. These maintain cross-workspace indices and now subscribe to schema changes from every workspace, including ones created at runtime.

Workspaces created through the API or by dropping a directory on disk are registered live — no restart needed for schema compilation, search indexing or route registration.

​Org-scoped authorizationNewSecurity

@RequiresOrgPrivilege replaces @PreAuthorize("hasAuthority(...)") across roughly 150 production endpoints. It resolves the request’s {orgId} path variable and delegates the decision to an OrgAuthorityService, which has two implementations:

• The default is org-blind and checks the flat authority set, preserving behaviour for single-org and non-PropelAuth deployments.
• When vyne.security.open-idp.roles.format=propelauth, per-org roles are read from the JWT’s org_id_to_org_member_info claim.

This unblocks users who belong to multiple organisations, who previously hit “You are a member of multiple organisations”.

Org membership is now enforced on the workspace endpoints themselves. Previously any authenticated user could list or create workspaces in any tenant by putting that tenant’s slug in the URL. Organisations are also auto-provisioned from JWT claims on first sign-in, so workspace creation works on a fresh deployment.

​CopilotNew

Copilot is a chat interface to your data mesh. It runs in two modes:

• Ask — natural-language questions answered by generating and running a TaxiQL query against the current workspace. “What’s Jim Patterson’s account balance?”, or “write me a query that joins orders to customers”.
• Build — an agent with file-editing tools that works on your Taxi projects, streaming its edits directly into the code editor beside the conversation.

The mode is chosen before you send the first message, and pinned for the life of the conversation — reopening a conversation restores the mode it was started with.

Conversations are persisted with their history, can be renamed, and are listed in a sidebar. File uploads are supported and scoped to the workspace. In Build mode, edits stream into Monaco models as they arrive, so you watch the agent write.

​Configuring it

Copilot is a separate service. Point Orbital at it and turn on the toggle:

vyne:  toggles:    copilot-enabled: true  copilot:    endpoint-url: http://localhost:9028    upload-store: local    local-store-path: ./orbital_data/copilot/uploads

Requests to the Copilot service carry the caller’s JWT, and all calls are scoped to the current org and workspace.

​MCP serverNew

Orbital exposes a Model Context Protocol server, so Claude, Cursor, IDE agents and your own tooling can ask the same questions a Copilot user can.

vyne:  toggles:    mcp-server-enabled: true

One endpoint is mounted per workspace:

/api/{orgId}/{workspaceId}/mcp

Mounting it under the workspace path means it inherits the existing org-membership gate from the security filter chain. No tool takes orgId or workspaceId as an argument — the URL is the only source, so an MCP client can’t reach across into another tenant’s data by changing a parameter.

The server exposes a single ask tool:

It answers with the natural-language answer, the generated query, a queryHistoryId you can use to inspect the run in Orbital’s history, the result rows, and any queryError or diagnostics.

The tool description and the server’s MCP instructions are generated from the workspace’s own schema, so clients know what data they’re pointed at.

Authentication accepts a PropelAuth API key presented the standard way — Authorization: Bearer <token> — which is what MCP clients send. Orbital now discriminates structurally: a bearer credential shaped like a JWT is validated as one, anything else is validated as an opaque API key. Previously an API key had to be sent without the Bearer prefix, which MCP clients can’t do.

​The new code editorNew

The old single-query editor is replaced by a multi-file editor at /code-editor.

• A real file tree. It walks the project on disk, so taxi.conf, READMEs, connections.conf, nebula scripts and everything else is visible — not just .taxi files. Content is fetched lazily when you click. Per-file error counts show in the tree.
• Split panels. Editors, query results and query history live in dockable panels you can arrange, and the layout persists across refreshes — keyed by workspace, so switching org or workspace doesn’t restore the wrong location’s panels.
• File lifecycle. Right-click to rename or delete. Both flow through the same compile-after-change pipeline as content edits, with atomic moves for renames.
• Save anything. Saving no longer runs every source in the package through the Taxi compiler and rejects the write on any error. Non-Taxi files are excluded from compilation entirely, and Taxi files with compilation errors save anyway, with the errors surfaced in the UI. The editor’s job is to write what you typed.
• Language support is auto-detected from the file extension. Markdown renders. Unmapped types open as plain text instead of failing.

Two long-standing editor bugs are fixed. Editing or saving a file used to produce Symbol X is already declared errors for every symbol in the file, caused by the same file being registered under two different URIs — once through the language server and once through the schema editor’s in-memory edit application. And edits to files outside src/ were being nested under src/, while edits already addressed with a src/ prefix were double-nested at src/src/....

​Secrets managementNew

Secrets are now first-class. Reference one anywhere in your config the same way you’d reference an environment variable:

connections.jdbc.warehouse {   url:      "jdbc:postgresql://warehouse.example.com:5432/prod"   password: ${secrets.DB_PASSWORD}}

Real values never enter the merged HOCON config. The placeholder resolves to an opaque token that the consumer resolves at the point of use — at connection time, at outbound-request time, at git-fetch time — so a secret lives in a call frame and never in long-lived state. Rotating a secret takes effect without a restart.

​Backends

Pick one with vyne.secrets.backend:

Each backend maps Orbital’s scope hierarchy onto its own naming rules — paths in Vault and Infisical, flat prefixed names in AWS, __-separated segments in GCP, whose names can’t contain slashes.

​Scopes

Reads cascade — workspace, then organisation, then server — and the narrower scope wins on a name collision. There is no global namespace that bypasses scoping.

​Managing them

Secrets are managed in the UI under Secrets, and over REST:

GET    /api/{orgId}/{workspaceId}/secretsGET    /api/{orgId}/{workspaceId}/secrets/{scope}POST   /api/{orgId}/{workspaceId}/secrets/{scope}PUT    /api/{orgId}/{workspaceId}/secrets/{scope}/{name}DELETE /api/{orgId}/{workspaceId}/secrets/{scope}/{name}POST   /api/{orgId}/{workspaceId}/secrets/refresh

Reads need LIST_SECRETS, writes need EDIT_SECRETS. No endpoint ever returns a secret value — responses carry name, scope, description, last-updated and version only. Server-scoped secrets are listable but operator-managed: writes to that scope are rejected with a 403.

A caller at /api/acme/prod/... can only touch Workspace(acme/prod) and Organisation(acme) — not another org’s or another workspace’s secrets.

Every backend is wrapped in a caching decorator with a 15-minute TTL (configurable via vyne.secrets.cache.ttl and .max-size), write-through invalidation, and the refresh endpoint above for forcing a reload after rotating a secret out of band.

​Git authenticationNew

Adding a git project now captures credentials — none, username/password, token, or SSH key — as references to secrets rather than as credentials embedded in workspace.conf and travelling through git. The UI rejects plaintext entries at submit, since they would defeat the point.

Credentials resolve inside JGit’s configure(transport) call. SSH keys load as bytes, so no key is ever written to a temp file.

See managing secrets for the full setup.

​Data validationNew

You can now declare validation rules against your types, and control what happens when data breaks them. Because rules are declared against types, you define them once and they’re enforced everywhere that type appears, whichever service the data came from.

Three parts: declare rules with annotations, activate them with @Valid, decide what happens with @OnValidationFailure.

import com.orbitalhq.validation.NotEmptyimport com.orbitalhq.validation.Valid
@NotEmptytype Name inherits String
@Validmodel Person {   name : Name}

A Person arriving as { "name": "" } produces one violation — rule com.orbitalhq.validation.NotEmpty, at path name, severity Error — and by default rejects the query with an HTTP 400. Remove the @Valid and the same data flows through untouched. Rules do nothing until something activates them.

​The built-in rules

@NotEmpty, @MinLength, @MaxLength, @Pattern, @Min, @Max, @MultipleOf, @MinItems, @MaxItems, @UniqueItems, @Email, @Uuid. That’s feature parity with OpenAPI’s schema validations. Every rule takes an optional message and severity (Info, Warning or Error).

Rules can go on a type, a field, or a query parameter, and they’re inherited — a rule on Name applies to every type inheriting from it.

Two rule ids are produced by the engine rather than declared: NotNull, when a non-nullable field inside a @Valid scope holds a null, and ParseFailure, when a value can’t be parsed into its declared type.

​Deciding what happens

@OnValidationFailure(action = ValidationAction.Warn, threshold = Severity.Error)query GetOrder {   find { Order }}

threshold sets the minimum severity that triggers the action. All violations are reported regardless of threshold — the threshold only decides which are severe enough to act on. That pairs well with per-rule severity: mark rules you’re not yet confident about as Warning, watch them in your logs, promote them to Error once you trust them.

Defaults are per query kind: find rejects at Error, stream drops at Error. Query arguments always reject — dropping a record makes no sense when the record is the caller’s own input.

Violation paths are precise: cast.actors[1].actor.name, not just “somewhere in the response”.

Validation runs on query arguments, on data returned by services, and on streaming pipeline inputs.

See validating data and the rule reference.

​Data sources

​OracleNew

Orbital now ships an Oracle driver, with full write support: Insert and generated-primary-key Upsert use INSERT ... RETURNING, Update runs per-row batches, and a user-supplied-PK Upsert uses MERGE. Oracle’s MERGE can’t return rows, so the invoker echoes the input back, matching how the Postgres upsert behaves.

Table generation accounts for Oracle lacking CREATE INDEX IF NOT EXISTS and needing explicit lengths on indexed VARCHAR2 / CLOB columns. jOOQ’s dialect is resolved by probing the live connection rather than assuming a version, so Orbital doesn’t emit CREATE TABLE IF NOT EXISTS (23ai and later only) against an older database. The probe is cached per connection.

Metadata reads are scoped to the connecting user’s schema. Oracle has no schema concept separate from the user, so without that scoping Orbital crawled SYS, SYSTEM and every other user’s schema.

​Database metadata is read directly, and scopedImprovedFixed

Table introspection — the connection UI’s table list, and the schema generator behind import from database — was built on SchemaCrawler, which required a full catalog crawl. On a warehouse that’s slow to the point of unusable, and it had no plugin support for Snowflake or Databricks.

It’s been replaced with targeted DatabaseMetaData calls. What that changes for you:

• The reactive server no longer stalls. listConnectionTables and getTableMetadata ran their blocking JDBC calls on the Netty event loop, which starved the whole server until it was restarted. They now run on a bounded elastic scheduler.
• Listing tables returns names only. Column, primary-key and index metadata were an extra round-trip per table, on a screen that only needs names. They’re opt-in now, via includeColumns / includeIndexes query parameters on the tables endpoint.
• Generating Taxi for one table is independent of database size. It reads the tables you asked for plus the ones their foreign keys reference, one level deep, rather than crawling the whole schema.
• Better type coverage. CLOB maps to String instead of failing generation outright, and Postgres domain types map to Any rather than erroring.

​Databricks and SnowflakeNew

Databricks is new. Hostname, port, HTTP path and token are the user-facing parameters; AuthMech=3 and UID=token are baked into the URL template so you don’t see them.

Snowflake existed as a twelve-line shell that had never been used in anger, with its JDBC driver commented out of the build because the fat jar broke shading. It’s been rebuilt: region is now an optional URL parameter, and the thin driver replaces the fat one — no shading problems, no broken native build.

Neither platform supports the ON CONFLICT syntax the other drivers use for upserts, so both build a MERGE INTO statement instead. That needs something to match existing rows on, so when a primary key column isn’t among the written fields — a @GeneratedId key, for instance — the write falls back to a plain INSERT and logs a warning. It’s a warning rather than a silent fallback because rows can duplicate under an @UpsertOperation when it happens.

Driver-specific column unwrapping moved off the base JDBC invoker onto the driver itself, so Postgres owns its PGobject / PgArray handling and any driver returning its own wrapper types can be supported cleanly.

​MongoDBNew

MongoDB connections can now be created and tested from the UI. The driver was already listed in the connections editor, but test and create posted nowhere — the UI had no URL mapping for NoSQL connectors and the backend had no endpoint. Both now exist, and MongoDB has a health-check provider like the other connectors.

​Connection failures surface properlyFixed

A database-backed saved query invoked through a routed HTTP endpoint used to return 200 OK with an empty body when its connection was undefined or unreachable — indistinguishable from a query that legitimately matched nothing.

Connectors now raise typed exceptions whose HTTP status comes from the exception itself:

JDBC connection failures are also reported as trace events, so they show up in the query profile rather than vanishing.

​Deletes and native SQLNew

@DeleteOperation gives you type-safe deletes through TaxiQL. A single @Id renders WHERE pk IN (...), composite keys use row-value IN, and statements are chunked at 500 rows to stay under Oracle’s IN-list cap. Values are always bound, never inlined. The operation returns a deletedCount.

@SqlQuery lets you write the SQL yourself — joins, aggregations, dialect-specific statements — for the cases where the generated query isn’t what you want. One annotation covers reads and native DML, split by taxi’s write keyword. Reads map joined and aggregated rows onto plain models by column name or alias, with no @Table needed; writes return the affected-row count.

:param placeholders bind as real prepared-statement parameters, validated against the operation’s parameters before execution. Values never touch the SQL text.

Both were announced in July, and this is the first build they ship in.

​Also

• Overriding a service in services.conf can now downgrade from https to http, which it previously refused to do.

​Query engine

​Collection options: limit, sort, paginate and dedupeNew

You can shape the results of a query directly in TaxiQL — limiting how many rows come back, paginating through them, sorting them, and removing duplicates:

find { Person[]( CountryCode == "GB", orderBy: DateOfBirth desc, offset: 20, limit: 10 ) }

limit, offset, orderBy and uniqueBy are the standard database-style controls, and they work on any query, against any source — not just databases.

Sort by more than one field, and paginate:

find { Person[]( orderBy: [CountryCode asc, DateOfBirth desc], offset: 40, limit: 20 ) }

They work on projections too, including nested collections, which is handy for trimming child records per parent:

find { Customer[] } as {  name : CustomerName  // Only the 20 most recent transactions per customer  transactions : Transaction[]( limit: 20, orderBy: TransactionDate desc )}[]

Values can be literals or query parameters, so limit: maxRows works when maxRows is a query argument.

Pushdown is decided per option, per data source. When a source can apply an option itself, Orbital pushes the work down to it; when it can’t, Orbital does it after fetching. Either way you get the same answer, and pushdown only happens when it can’t change the result — if a source can’t sort, Orbital won’t push a limit below the missing sort, because limiting before sorting returns the wrong rows.

uniqueBy is never pushed down; it’s always applied by Orbital. Operations annotated with @SqlQuery opt out of pushdown entirely, since options can’t be spliced into SQL you wrote by hand — they’re applied after the fetch instead.

On streaming queries, limit is supported and completes the stream once it has emitted N items. orderBy, offset and uniqueBy are rejected on streams, as is cursor pagination (after / before), which parses but is not yet implemented.

This was announced in July — 0.39.1-M1 is the first build it ships in. Full detail is in the collection options docs.

​Operation parameters are gathered consistentlyFixed

Parameters were being gathered in four separate places that disagreed with each other: the mutation path, the graph-search path, the direct-invocation path, and again inside the invoker. The same call could bind a value to the wrong parameter on one path, send null on another, and ignore a declared default entirely on a third. An operation could also be invoked with fewer arguments than it declares, because the graph path caught any discovery failure and quietly dropped that parameter.

There is now one shared implementation returning an explicit map of parameter to value. Callers differ in what they do when it can’t be satisfied — direct invocation tries another candidate, graph search fails the edge, mutation returns a null — but they all gather the same way.

The operation-result cache is keyed off that map, too. Keyed off a set, as it was, getEligibility(orderId=A, lineId=B) and getEligibility(orderId=B, lineId=A) shared a cache entry.

Nullable parameters that can be constructed from context now are. Previously discover short-circuited to null the moment it saw a nullable parameter, so a nullable request body whose fields were all present in context was sent as null.

​Circular type references no longer blow the stackFixed

A model whose definition leads back to itself — total : Total = (Total * 1.2), or a pair of types whose expressions reference each other — recursed until the JVM threw StackOverflowError.

A closed loop now yields a null carrying the cycle path — Order.total -> Order.total, or A -> B -> A — rather than throwing. Circular definitions are now legible, not valid; they remain unsatisfiable.

This matters more than it looks. StackOverflowError isn’t recoverable the way an exception is: if it lands while a class is initialising, that class stays unusable for the life of the JVM and every later touch throws NoClassDefFoundError. We hit exactly that during a benchmark run — it broke coroutine cancellation process-wide, with no error naming the cause.

​Collecting arrays across collection boundariesFixed

A query like find { GivenName[] }, against a response whose givenNames sit two collection layers deep inside the returned object, failed with “no data sources can return GivenName[]”. The query graph only had scalar attribute edges, so there was no path.

There’s now an edge from each provided instance to every T[] reachable via a path crossing at least one collection field. Its cost sits between cheap attribute navigation and remote operation invocation, so a direct attribute path still wins when one exists, but the planner always prefers in-memory extraction over calling a service again.

A service returning no matching instances yields an empty T[] rather than failing the query.

​Query errors reach the error viewFixed

Several places in the engine caught exceptions and returned a null or an empty result without telling anyone, so genuine failures never reached the query error view. Failures that are actually meaningful — a nullable operation parameter that couldn’t be constructed, unexpected exceptions while searching for a type — now publish to the error stream that feeds the errors websocket and query history.

Routine search backtracking is deliberately left silent. It’s normal control flow, it fires per row during projection, and surfacing it would flood the view with alarming noise.

Separately, fast-failing queries used to tear down their error stream before the UI could connect to it, so the same query would only intermittently show its errors. The error publisher keeps a 30-second replay buffer for exactly this reason; eviction is now deferred past the replay window so a late-connecting websocket can still drain it.

​Also in the engineFixed

• A TaxiQL statement that fails to compile returns 400 Bad Request rather than 500.
• Failed searches capture where and why they failed, with a readable display of the failure point.
• Graph search error reporting is more informative, and the error message now hints when a find with a contract would be better expressed as a given {}.
• Fact-bag lookups had lost their combine, dedupe and absent semantics when they moved to an Either-based API: deep searches silently dropped all secondary-bag matches whenever the primary bag had any match, merged collections skipped deduplication, and “absent everywhere” was reported as an empty collection rather than a null — which stopped the object builder falling through to discovery. All three are restored.
• Data policies are no longer applied to primitive types.
• Projections no longer attempt to construct scalar types, and fields carrying expressions are deferred to expression evaluation rather than being built directly.
• Object construction no longer throws when the type is nullable, matching field construction.

​PerformanceImproved

This milestone adds a benchmark suite and CI guards rather than a broad optimisation pass. query-engine-benchmarks carries seeded synthetic schema and data generators, 13 workloads, 7 JMH micro-benchmarks, and a guard suite that gates merge requests on deterministic metrics — operation invocation counts, allocation budgets, complexity-class scaling ratios and heap-slope leak checks — while tracking wall-clock time as a nightly trend rather than a flaky gate.

One fix landed alongside it: fact-bag search caching now validates lazily on read against a generation stamp, so adding a fact is O(1) rather than doing predicate work proportional to every cached search. Measured 86–93% off addFact, with lookup cost flat.

A full review of the engine’s performance characteristics is written up internally. The remaining findings are the fix programme for subsequent releases, and each has a matching benchmark guard waiting to be switched on.

​UIImproved

The navigation has been reorganised:

​EndpointsNew

The endpoint page is now tabbed, matching the catalog layout:

• Overview — query plan diagram and metrics
• Schema — the model attribute tree for the query’s return type
• OpenAPI — a generated OpenAPI spec, for non-streaming queries
• Source — the query source

A new endpoint, GET /api/schemas/queries/{queryName}/openapi, generates the spec for any saved query by name. The existing /api/q/meta/{queryName}/oas only covered HTTP-routable queries.

Published query URLs shown in the UI now match where the endpoint is actually served — previously the raw declared URL was shown, which didn’t match the workspace-prefixed route.

​Local environmentsFixed

Three unhappy paths on the Local Environments page used to fail silently or mislead:

• Compilation errors. A nebula script that failed to compile produced no feedback at all — the Nebula server killed the websocket handler. Per-stack compilation errors are now accumulated and listed against their stack, clearing when a corrected version compiles.
• Disconnected empty state. With nebula files defined but the server unreachable, the page claimed no environments were defined. It now shows “Waiting to connect…” with the names of the stacks it knows about from the schema.
• Component start failures. An invalid DDL or similar now shows its message in the tree tooltip, as a banner on the component detail panel, and as a red Failed state in the status bar — which previously showed “Starting…” forever.

Two connection bugs are fixed too. A dropped session (a network blip, or a non-text control frame) used to kill the consumer coroutine permanently: the socket kept reconnecting and logging that it had connected, but nothing consumed the new sessions, so schemas were never resubmitted. And rapid status transitions were being dropped — the in-process HTTP component fires Starting and Running microseconds apart, and the sink was configured to drop an update for every subscriber if any one of them was momentarily at zero demand, leaving consumers stuck on “starting” forever.

Projects that reference NEBULA_* environment variables no longer flash a red config-errors banner at startup while the local stack is still coming up. Orbital distinguishes “Nebula starting” from a real config failure and shows a quiet “Starting local environment…” instead, escalating to a proper error if the connection drops.

​Query graph debuggerNew

The old Angular graph-vis tool is replaced by a React Flow rewrite under tools/graph-debugger. Paste the graph the engine logs while planning a query and explore it interactively to work out why a query isn’t resolving.

Large graphs used to lock the canvas, so it now starts empty: add a single type, expand outward from any node via its off-canvas-neighbour badge, or drop the whole graph on at once for small ones. Auto-layout is left-to-right hierarchical, matching the engine’s traversal direction, and dragging a node pins it.

​Smaller UI fixesFixed

• Picking a result in the search bar navigated twice — once to the item you chose, and again to the first item in the list.
• The schema diagram’s markdown round-trip now serialises member keys as qualified names, so saved layouts resolve on re-render.
• Clicking a model node header in the schema diagram navigated to the literal path rather than the type’s qualified name.
• Operation parameter type names link through to the catalog, matching the return type’s behaviour.
• Query plans containing a Hazelcast node no longer throw.
• Loading buttons inside pop-ups are no longer obscured by incorrect styling.
• Alert action links (project errors, config errors, compilation errors) navigate to the correct workspace.
• A 404 for a type that doesn’t exist no longer bounces you out to the workspace selector — only a genuine workspace-not-found does.

​Other fixesFixed

• HTTP header parameters were matched by position, not name. buildHttpHeaders resolved each @HttpHeader parameter by its index in the supplied list, assuming that list matched the operation’s declared parameter order. It doesn’t — directly-provided parameters are appended after searched ones — so header values could silently be attached to the wrong header.
• A JDBC driver returning null threw an NPE rather than producing a null value.
• Config loading could throw ConcurrentModificationException because custom types were being registered on every load rather than once at class initialisation.
• An invalid PropelAuth API key returned 500. It now maps to 401 for a rejected token, 403 for a permitted token without access, and 503 when PropelAuth itself is unreachable.
• A file watcher missed the contents of newly created directories. java.nio.WatchService doesn’t replay events from before a key is registered, so writing orbital/config/services.conf in one go meant the watcher saw only the orbital/ directory and never the files inside it. Creating a directory now registers the watch and walks its existing contents.
• Sankey lineage rows weren’t stamped with the query’s workspace, so the lineage view in the query profile was empty for every workspace-scoped query.
• History results for PROVIDED lineage nodes weren’t showing.
• Trace events from published-query routes were stamped with the default workspace rather than the one that ran the query.

​In case you missed it

Writing these notes turned up a gap in our own record-keeping. 0.36.0 (October 2025) and 0.38.0-M1 (June 2026) both shipped without a release announcement, and a handful of point releases went out quietly too. A fair amount of work reached you without us ever saying so.

None of this is new in 0.39 — it’s all been in your hands for a while. It’s here because you may not know you have it.

​Custom Kotlin functionsNew

You can extend Taxi’s standard library with your own functions, written in Kotlin and loaded at runtime. Declare the function in Taxi, implement it in Kotlin, and it’s available in expressions, projections and queries like any built-in.

This is the extension point to reach for when a transformation can’t be expressed in Taxi itself — a proprietary check-digit algorithm, a domain-specific parse, an internal encoding scheme.

It’s documented at custom functions; it has simply never appeared in a changelog, because 0.36.0 never got one.

It’s also the mechanism the validation framework will use when user-written validation rules land — the loader is already proven.

​Everything else

The undocumented rows are on our list. If one of them is something you’ve wanted, tell us and we’ll bump it.

​Upgrading

This is a milestone build. Try it somewhere that isn’t production first.

1. Read Breaking changes — particularly the license requirement and the workspace-mode toggle rename.
2. Back up your query history database. The Flyway migration takes table locks to enforce the new non-null columns.
3. If you use H2 as a data source, migrate off it before upgrading.
4. If you rely on the standalone Jet pipeline server, stay on 0.38.x. Streaming queries are unaffected.
5. Start Orbital and sign in. Your free license downloads automatically.

Workspaces are opt-in. Leave workspace-mode at None and Orbital behaves as it always has, with a single workspace and legacy routes intact — you can adopt workspaces when you’re ready.

(The post 0.39.1-M1 - Workspaces, Copilot, secrets and validation appeared first on Orbital Changelog.)

Two additions to our database connectors in this release: deleting rows through TaxiQL, and running SQL you’ve written yourself.

​Deleting rows

Databases connected to Orbital have long supported reads, inserts, updates and upserts. Deletes now join the family - annotate a write operation with @DeleteOperation:

@DatabaseService(connection = "customers-database")service CustomerService {   @DeleteOperation   write operation deleteCustomer(Customer):DeleteResult
   @DeleteOperation   write operation deleteCustomers(Customer[]):DeleteResult}

Rows are matched on the model’s @Id fields (composite keys work too - rows match on the combination), and you can pass a single instance or a whole array. Invoking it looks like any other mutation:

given {   customers : Customer[] = [      { id : 123 },      { id : 456 }   ]}call CustomerService::deleteCustomers

You get back a deletedCount telling you how many rows went away. Deletes run in a single transaction, so a failure partway through rolls the whole thing back rather than leaving you half-deleted.

​Native SQL queries

Orbital’s table operations cover most day-to-day querying, and keep your queries portable across databases. But sometimes you just want to write the SQL yourself - a join, an aggregation, or something dialect-specific. The new @SqlQuery annotation is that escape hatch:

@DatabaseService(connection = "films-database")service FilmStats {   @SqlQuery(sql = """      SELECT d.name AS director, COUNT(f.id) AS filmCount      FROM film f      JOIN director d ON f.director_id = d.id      GROUP BY d.name   """)   operation filmsPerDirector() : DirectorFilmSummary[]}

The SQL is passed to your database exactly as written, and result columns map back to your Taxi model’s fields by name or alias. One annotation covers both directions: a plain operation runs the SQL as a query, while a write operation runs it as a statement (UPDATE, DELETE, INSERT) and returns the number of rows affected.

Operation parameters bind into the SQL with the :parameterName syntax:

@SqlQuery(sql = "SELECT title, release_year AS releaseYear FROM film WHERE release_year > :year")operation recentFilms(year : ReleaseYear) : Film[]

Values are always bound as prepared-statement parameters - never spliced into the SQL text - so user-supplied values can’t alter your query.

Both features work across all of Orbital’s SQL database connectors. Full details are in the database docs, including native query behaviour notes.

(The post Database connectors: delete support and native SQL queries appeared first on Orbital Changelog.)

You can now shape the results of a query directly in TaxiQL - limiting how many rows come back, paginating through them, sorting them, and removing duplicates. We’re calling these collection options, and they look like this:

find { Person[]( CountryCode == "GB", orderBy: DateOfBirth desc, offset: 20, limit: 10 ) }

These are the standard database-style controls we all already know and love - limit, offset, orderBy and uniqueBy - but they work on any query, against any source.

When the source can apply an option itself, Orbital pushes the work down to it. When it can’t, Orbital does the work after fetching. Either way you get the same result.

​A few examples

Sort and take the top N:

find { Film[]( orderBy: RottenTomatoesScore desc, limit: 10 ) }

Sort by more than one field, and paginate:

find { Person[]( orderBy: [CountryCode asc, DateOfBirth desc], offset: 40, limit: 20 ) }

Options work on projections too, including nested collections - handy for trimming child records per parent:

find { Customer[] } as {  name : CustomerName  // Only the 20 most recent transactions per customer  transactions : Transaction[]( limit: 20, orderBy: TransactionDate desc )}[]

Values can be literals or query parameters, so limit: maxRows works just as well when maxRows is a query argument.

​How pushdown works

For each option, Orbital’s query planner decides - per data source - whether to push it down or to apply it itself.

Pushing down tot he source system is only permitted if it doesn’t change the answer: if a source can’t sort, Orbital won’t push a limit below the (missing) sort either, because limiting before sorting would hand back the wrong rows.

Here’s what’s supported in this release:

• SQL databases (Postgres, MySQL, MSSQL, Oracle, Redshift, Snowflake) push limit, offset and orderBy straight into the generated SQL, in the right dialect for your driver.
• MongoDB pushes limit, offset and orderBy into the Mongo query as sort / skip / limit.
• Hazelcast pushes limit down as a key-ordered page; everything else is applied by Orbital.
• Everything else - REST APIs, Kafka, and any other source - is applied by Orbital after fetching. No source-side support required.

limit also works on streaming queries, completing the stream once it has emitted N items.

​Coming next

after / before cursors are reserved for cursor-based pagination and will land in a future release - for now they parse but are rejected at runtime.

Full details are in the collection options docs, and the syntax reference lives in the Taxi language docs.

(The post Collection options: limit, sort and paginate any query appeared first on Orbital Changelog.)

​Anonymous access for published queries

Queries published as HTTP endpoints can now opt out of authentication on a per-query basis using the new @com.orbitalhq.authentication.AllowAnonymous annotation.

When Orbital is deployed with an authentication provider configured, all published query endpoints require a valid token by default. @AllowAnonymous relaxes that requirement for a single query — useful for health checks, public catalogues, or any endpoint intended to be reachable without a token. Other queries in the same workspace are unaffected.

import taxi.http.HttpOperationimport com.orbitalhq.authentication.AllowAnonymous
@HttpOperation(url = '/api/q/healthcheck', method = 'GET')@AllowAnonymousquery Healthcheck {  find { status: String = "ok" }}

The annotation only affects the authentication check. Data policies and authorization rules still run.

See the docs on allowing anonymous access for more detail.

(The post 0.38.0 - Anonymous access for published queries appeared first on Orbital Changelog.)

As part of upcoming feature work for improved SDK tooling for JVM and TS/JS ecosystems, there are two breaking changes to the query API are shipping in 0.38.x (and nightly builds of next). Neither affects 0.37.x.

​Breaking: /api/taxiql no longer accepts application/json

The /api/taxiql streaming query endpoint previously accepted requests with Content-Type: application/json. This is no longer supported.

Use either of the following content types instead:

• application/taxiql (Preferred, but less standard)
• text/plain (Standard, but less accurate)

Either are fine to use, and both content types are already supported in all versions of Orbital today, so you can make this change now, without waiting.

If you’re sending queries via curl or an HTTP client, update accordingly:

# Before (no longer works)curl -X POST /api/taxiql \  -H "Content-Type: application/json" \  -d '{ "query": "find { ... }" }'
# Aftercurl -X POST /api/taxiql \  -H "Content-Type: application/taxiql" \  --data-raw 'find { ... }'

​Removal of /api/vyneql

The legacy /api/vyneql endpoint has been removed. It was a holdover from the previous product name and has been superseded by /api/taxiql for some time. If you were still referencing /api/vyneql, update your calls to use /api/taxiql.

(The post Breaking change: /api/taxiql content-type and removal of /api/vyneql appeared first on Orbital Changelog.)

The headline features are a new parseJson() standard library function, the ability to export query history as Preflight test specs, and a significant improvement to observability — with request parameters now captured on every remote call across all connectors.

There’s also a crop of reliability improvements: better git sync resilience, a fix for a stack overflow in the query engine, and an internal overhaul that removes a class of thread-pool starvation under concurrent load.

As a milestone release, 0.37.0-M3 is intended for early adopters and teams that want to test ahead of the GA release. Feedback welcome.

​New Features

​parseJson() stdlib function

You can now use parseJson() in your queries and projections to parse a JSON string into a typed value.

This is useful when JSON arrives embedded in a field as a string — a common pattern in event-driven systems where a message envelope wraps a serialized payload.

​Preflight test spec export

Query history can now be exported as a Preflight test spec, in addition to the existing ZIP regression pack format.

When downloading a regression pack from query history, you can now choose between Zip (the original format) and Preflight spec files.

Preflight Spec Files are markdown files that describe a test scenario, along with all the information to stub out query services:

---spec-version: 0.1--- # Test name Optional description paragraph. ## Query ```taxiqlfind { Customer( CustomerId == "C-100" ) } as CustomerProfile``` ## Data Sources ### Customer API<!-- operation: getCustomer --> Response:```json{ "id": "C-100", "name": "Alice Smith", "age": 30 }``` ## Expected Result ```json{ "id": "C-100", "name": "Alice Smith", "age": 30, "isAdult": true }```

By capturing these using the data from your queries, you can very quickly build test suites for your taxi projects.

Preflight tests are runnable using Gradle, so works great with established build tooling and CI/CD.

​Observability

​Request parameters captured on trace events

The capture of input parameters for events shown in the Trace View has been extended, capturing inputs across all connectors.

​JFR flight recorder

Orbital now supports capturing Java Flight Recorder traces for capturing diagnostic data. This feature is disabled by default, but can be enabled through configuration

0.37.0-M3 extends this to further capture exception data.

​Reliability & Performance

​Query engine: fix for circular operation types (ORB-1081)

Fixed a bug where an operation whose return type also appeared as an input parameter type would trigger recursive parameter construction, ultimately causing a stack overflow. Type-level cycle detection is now applied during object building, so these circular type graphs are handled cleanly.

​Git sync failures are no longer fatal

A git repository sync failure at startup is now treated as a warning rather than an error. If a locally-cached copy of the schema is available, Orbital will use it and continue running — reporting a WARNING state in the UI rather than refusing to start.

The UI also now distinguishes between ERROR (schema could not be loaded at all) and WARNING (schema loaded from local cache), with separate alerts and colour-coded severity badges, so it’s clearer what’s actually happening.

A rate limiter (via resilience4j) has also been introduced on git repository polling, to prevent remote git servers from denying requests when Orbital is polling frequently.

​Eliminated blocking calls from the query engine

The internal TaxiQL query engine has been refactored to remove blocking calls. Under specific conditions, it was previously possible for the query engine to get into thread starvation, waiting for I/O calls to complete.

By migrating the core query engine away from blocking, this removes the risk

(The post 0.37.0-M3 - Preflight exports, parseJson, and observability improvements appeared first on Orbital Changelog.)

​New Features

• Added support for multiple authentication tokens per service (ORB-1065)
  • Services can now use multiple authentication mechanisms simultaneously (e.g., API key header + query param)
  • Define an array of auth schemes instead of a single object in auth.conf
  • Fully backwards compatible with existing single-scheme configurations

​Example

authenticationTokens {  "com.foo.service.*" [    { type: HttpHeader, value: ${API_KEY}, headerName: X-API-KEY },    { type: QueryParam, parameterName: apiKey, value: ${API_SECRET} }  ]}

There are no other functional changes in this release.

(The post 0.36.6 released appeared first on Orbital Changelog.)

​Bug Fixes

• Updated Taxi version to 1.69.1 to fix incorrect “Enum does not contain a member of” compilation errors (ORB-1064)
  • Fixed poor state management and hashcode handling when enum synonyms (extensions) are used
  • This resolves false positive errors that could occur when working with enum types that have synonyms defined

There are no other functional changes in this release.

(The post 0.36.5 released appeared first on Orbital Changelog.)

​New Features

• Added a flight recorder endpoint for debugging purposes (disabled by default)
  • Provides JVM Flight Recorder data for performance analysis and troubleshooting
  • Can be enabled via configuration when needed for debugging

There are no other functional changes in this release.

(The post 0.36.4 released appeared first on Orbital Changelog.)

​Bug Fixes

• Fixed buffer overflow when writing very large lineage records (ORB-1054)
• Increased maximum message size from 16MB to 64MB
• Added warning logging when messages are too large

There are no other functional changes in this release.

(The post 0.36.3 released appeared first on Orbital Changelog.)

​New way to start Orbital - start.sh

We’ve updated the way people get started on Orbital - replacing our docker-compose.yml with a bash script.

If you head over to orbitalhq.com, you’ll notice that we’re now asking people to start by curling:

curl -sSL https://start.orbitalhq.com/start.sh | bash

You can view the bash script - it’s still running the same docker-compose.yml, but we’ve just added some scripting to make the experience a bit better.

​What do I need to do?

There’s very little that’s changed.

You should add --vyne.app.data.path=/a/path/for/your/config to your config. It’s safe to do this now, before 0.37.0 is released.

It’s also safe not to do this at all, and Orbital will work with reasonable defaults. But, our new preferred config includes setting this property.

​What we changed:

• By default, the app now launches with user permissions, rather than root
• All app data (license files, temporary write queues, lucene search indices) are now written to the same, configurable directory (--vyne.app.data.path)
• Docker Volume directories are created before docker starts

​Why we did this - the pains of Docker Compose

We still ❤️ Docker Compose - it’s our preferred way for people to start the stack. But, we hit issues that made the experience unpleasant for developers…

​File permissions

When you’re working with Orbital, we expect you’ll do some stuff inside the browser, and other stuff inside your IDE.

However, if Docker creates the directories you’re using - even if your docker container is running with a non-root user, then you can end up with file permissions errors. You - the user - lack the permissions to edit the files that get created.

The start.sh fixes this by simply creating the directories before docker launches,

​User permissions

Telling Docker Compose to launch in a non-root user is slightly trickier than you’d expect. It’s not hard, but you can’t say “run with my account”, you have to say “run with this account”.

The idiomatic way to address this is:

services:       orbital:      image: orbitalhq/orbital:${ORBITAL_VERSION:-next}      user: "${UID}:${GID}"

And then have a .env file that defines those variables:

UID=1000GID=1000

This isn’t difficult, but it’s awkward for a user to just get started. So, the script handles this for you.

​Networking

Orbital is an integration platform, so when we ship demos or test stacks, we need things to integrate.

We solved that by building Nebula to deploy local environments. However, Nebula deploys other docker containers - and docker-launching-docker varies between OS’s. That meant our docker-compose.yml is OS-specific. We built tools to detect and try to serve the correct docker-compose.yml, but it’s clumsy if you’re running from the command line.

Our script detects which OS you’re running on, and downloads the correct docker-compose file for you.

​Summary

That it! The new launcher script is live now, and config variables are shipping now in next and will be part of the 0.37 release.

Happy integrating.

(The post New start script, and changes to default config appeared first on Orbital Changelog.)

​Bug Fixes

• Fixed broken persistence in lineage, caused by attempting to write taxi definitions (ORB-1052)

There are no other functional changes in this release.

(The post 0.36.2 released appeared first on Orbital Changelog.)

There are no other functional changes in this release.

(The post 0.36.1 released appeared first on Orbital Changelog.)

Previously, arrays were not being correctly type checked, such that this was possible:

The same type checking would also fail with arguments to functions or expression types:

These now correctly return compilation errors.

This is a breaking change, as these statements did not used to return compilation errors (but would not behave as expected).

This change will be released in 0.36, and is available from 0.36.0-M9

(The post Breaking change - improved type checking with arrays in 0.36 appeared first on Orbital Changelog.)

Orbital 0.35.0 brings significant enhancements to core capabilities, with major improvements to streaming, caching, and model handling.

This release focuses on stability and performance, particularly for high-volume data processing scenarios.

​Partial models

Partial models create variations of existing models where all fields are optional. This pattern is especially useful for API operations that support partial updates (PATCH), allowing clients to send only the fields they want to change.

model Customer {   id: CustomerId inherits String   name: CustomerName inherits String}   // Creates a new model where all fields are optionalpartial model CustomerUpdate from Customer

When you create a partial model, all fields become optional (nullable), including:

• Nested objects: Automatically converted to partial versions
• Collections: Arrays become arrays of partial versions
• Self-references: Updated to reference the partial version
• Annotations from the source model are merged with annotations on the partial model
• Modifiers are inherited with one exception: partial models cannot be closed

This all combines well with the @OmitNulls annotation to ensure null fields are excluded from serialized payloads:

// Original model with required fieldsmodel Product {   id: ProductId inherits String   name: ProductName inherits String   price: Price inherits Decimal   category: Category   tags: Tag[]}
// Create a partial version where everything is optional@OmitNullspartial model ProductUpdate from Product
service ProductCatalog {   // Full replacement (PUT)   write operation replaceProduct(Product): Product      // Partial update (PATCH)   write operation updateProduct(ProductUpdate): Product}

​OpenAPI, Avro and Protobuf in a taxi project

We now support including OpenAPI, Avro and Protobuf files directly within a taxi project.

Add entries in the additionalSources block of your taxi.conf, as shown below:

name: taxi/mixed-sourcesversion: 0.3.0sourceRoot: src/additionalSources: {   "@orbital/avro" = "avro/src/*.avsc"   "@orbital/openapi" = "openapi/*.yaml"   "@orbital/protobuf" = "proto/src/**/*.proto"}

These sources are automatically read, along with their taxi annotations, and imported into your taxi project.

This simplifies setups (and startup times) for teams where each spec was previously imported as standalone projects.

​Parallel streaming

When running Orbital in a cluster, background stream jobs can now be configured to run in parallel, which controls the number of nodes in the cluster that will execute the stream.

using the @Parallel annotation.

For example, assuming Orbital is deployed in a 6-node cluster, consuming events from Kafka.

import com.orbitalhq.streams.Parallel   @Parallel(count = 4)query MyStream {   stream { CustomerLoggedInEvent }   call MyMongoDb::upsertCustomerMetrics}

In this configuration, 4 of the nodes will subscribe to Kafka, and consume the events.

Orbital correctly rebalances as nodes enter and leave the cluster.

Learn more in the streaming data docs

​Improved caching controls

The @com.orbitalhq.caching.Cache annotation offers control over caching behavior at both operation and model levels.

You can disable caching for specific operations or data types, or adjust cache expiration with configurable time-to-live settings.

This helps balance performance needs when working with both static reference data and changing values in long-running stream processors.

Read more about configuring caching in the caching docs

​Azure service bus

We added support for Azure Service Bus, enabling integration with Azure messaging infrastructure through a full-featured connector.

Read more in the Azure Service Bus docs

​Other updates

​Enhanced Model & Query Capabilities

• Nested Projections with Multiple Scopes: Fixed support for nested projections with multiple scope variables, eliminating the “How to handle multiple scoped facts here?” error.
• Operation Input Improvements: Operations can now accept inputs populated by supertypes, enabling more flexible service invocation.
• Added ability to use expressions and constraints on the left-hand side of type references. [ORB-932]
• Object build type searches now correctly consider constraints. [ORB-895]
• Improved support for constraints on nested chained projections. [ORB-897]
• Spread Operator Improvements: Fixed spread operator to properly consider inherited types. [ORB-891]

​Streaming Enhancements

• Added low-cardinality error reporting for streams, providing better visibility into failures during stream processing.
• Fixed error reporting in streams so stream failures are accurately reported in the UI. [ORB-868]
• Streaming queries with a mutation operation now continue even if the mutation operation fails. [ORB-934]

​HTTP Improvements

• HTTP Retry Reporting: Fixed reporting of retried HTTP service calls in the profile window, improving visibility of retry attempts for operations with the @HttpRetry annotation. [ORB-931]

​Operational Improvements

• Improved Error Reporting: Enhanced error reporting when variables are missing in queries, providing more meaningful feedback to developers.
• Metrics & Monitoring: Multiple improvements to stream observability, including better error reporting, status monitoring, and metrics collection.

​File Monitoring

• Git Project File Watching: Added support for polling file watchers with Git projects, providing more reliable file change detection in certain environments. [ORB-865]
• Empty Workspace Configuration: Added ability to configure file monitoring settings for automatically created empty workspaces.
• Authentication Improvements: Fixed issue where updates in auth.conf were not reflected in Orbital Query Execution. [ORB-943]

(The post Orbital 0.35 - Partial models, mixed-source projects, parallel streaming, improved caching appeared first on Orbital Changelog.)

​Orbital 0.33.0 - “Growing Pains” Edition

Orbital 0.33 is out - with lots (and lots) of small, incremental improvements to the features you already know and love.

Sure, we skipped 0.32 - but who hasn’t had an episode in early 30’s they forgot?

Because this release is all about beloved features growing, and squashing bug fixes, and because we made a bold choice shortly after Dry January finished to name each of this year’s releases after an 80’s sitcom, we’re proud to present Orbital 0.33 - The Growing Pains edition.

​Highlights

• Improved UX: landing page and query editor improvements
• Orbital is simpler to deploy, as we’ve merged the Stream Server into Orbital
• Improved S3 connector
• Streaming queries observable over Http endpoints
• Avro support
• Lots of bug fixes

​A new landing experience

We’ve completely redesigned the landing page and now surface insights into the health of your project’s connections, an at a glance overview of schema changes, as well as metrics on currently running services.

We’ll be adding more content in this area as well, to help get new users up to speed, and provide more experienced users with documentation and tutorials to improve their Orbital productivity. Watch this space!

​Improved Query Editor experience

You asked for it, and we listened - tabs are now part of the query editor experience!

Create as many queries as you like, safe in the knowledge that you can tweak and edit them in isolation, and run the query when you’re satisfied things are looking good.

Results are retained for each tab, allowing some serious multitasking.

We’ve also overhauled the query editor’s toolbar, allowing you to publish queries to endpoints, and remove them if they’ve already been published. Alongside that, you’re now able to see which queries have endpoints associated with them, launch the endpoint, or copy the endpoint URL or code for a cURL command.

We’re confident these UI additions further improve the developer experience, let us know what other improvements in this space you’d like to see.

​Stream server is now folded into Orbital

The Stream Server historically was a standalone service that was responsible for executing long-running streaming queries.

It’s now folded directly into Orbital, simplifying the deployment significantly.

​Improved S3 connector

Our S3 connector received a much-needed makeover.

When reading, we now support reading from either a single file, an entire bucket, or any type of wildcard glob pattern. Files on S3 are also now supported as a standard write target.

We also support reading and writing to S3 in any of Orbital’s supported formats.

This means you can now do things like query a database, enrich it against a series of APIs, and write the results to a csv file on an S3 bucket. Alternatively, you can read a CSV file from S3, split it, enrich each record and write the values to Kafka.

For example:

// Given a model of data stored on S3:@Csvmodel TradeSummary {   symbol : Symbol inherits String   open : OpenPrice inherits Decimal   high : HighPrice inherits Decimal   close : ClosePrice inherits Decimal}
// Expose the S3 bucket:@S3Service(connectionName = "MyAwsConnection")service AwsBucketService {    @S3Operation(bucket = "MyTrades")    operation readBucket(filename:FilenamePattern = "trades.csv"):TradeSummary[]}
// Expose some enrichment services:service TradeVolumeApi {   @HttpOperation(url="https://myTradeService/volumes/{symbol}", method = "GET")   operation getTradeVolumes(@PathVariable("symbol") symbol : Symbol): TradeVolumes}
// Expose our enriched data model:model TradesWithVolumes {  symbol : Symbol  prices :  {     open : OpenPrice     close : ClosePrice  }  volumes : {    volumes : TradeVolumes  }}
// And a Kafka topic to write to:service MyKafkaBroker {   @KafkaOperation(topic = "tradesWithVolumes")   write operation publishTrades(TradesWithVolumes):TradesWithVolumes}
// Given the above, we can fetch from S3, transform against our// enrichment API, and write the results to Kafka using the following// query:find { TradeSummary[] )call MyKafkaBroker::publishTrades

See more examples in the docs for the S3 connector.

​Kafka headers and message key are now available

You can now access the message key for a Kafka message directly in your model:

import com.orbitalhq.kafka.KafkaMessageKey
model Movie {  // The key from Kafka will be read into the id property  @KafkaMessageKey  id : MovieId inherits String  title : Title inherits String}

Similarly, Kafka message headers can now be provided using the @KafkaMessageMetadata annotation

More details are available in the updated Kafka documentation

​Streaming queries are observable via Http endpoints

Orbital has supported saved streaming queries for some time. These run in the background doing things like consuming from a Kafka topic (amongst others), transforming, enriching and writing data.

Now, these same queries can be observed via HTTP endpoints - using either Server Sent Events or Websockets. Simply add an annotation to your query definition:

@HttpOperation(url = '/api/q/newReleases', method = 'GET')query getNewReleaseAnnouncements {  stream { NewReleaseAnnouncement } as {    title : MovieTitle    reviewScore : ReviewScore  }[]}

These annotations can also be added by using the new publish endpoint feature detailed in the query editor improvements

This query would be available over Curl using

curl -X GET 'http://localhost:9022/api/q/newReleases' \  -H 'Accept: text/event-stream;charset-UTF-8'

More details are available in the documentation for saved streaming queries.

​Avro format

We’ve added support for Avro as a format - both reading and writing.

Additionally, we also support Confluent’s own, special, magical version of Avro, which injects a few additional bytes at the start … “magic bytes” — their words, not ours. Anyway, we support reading this, without a dependency on the Confluent schema server.

Find out more about Avro support in the Avro documentation

​Batched writes for Mongo

Orbital can now batch upserts target to a Mongo Collections. See the documentation for details.

​Batching mutations

Previously, mutations were run incrementally in parallel.

You can now optionally indicate that a mutation should be performed at the end of the query, after all projections have been completed. This is useful for targets like S3, where incremental writing isn’t supported.

More information and examples are available in our updated docs on mutations.

​Other features:

• Configurable groupId for a Kafka connection
• Better configuration options for Hazelcast connections

​Bug Fixes

​Performance

There’s been a number of performance improvements across the stack:

• Fixed bottleneck when queries don’t use a projection in a mutation
• Fixed performance writing to Hazelcast maps
• Fixed performance issues with @Cache annotated queries
• A number of minor tweaks to the core query engine to improve performance
• We’ve fixed issues making it very slow to parse database metadata (when importing a database table)

​Relative paths in workspace.conf

Some customers like to manually deploy their taxi projects onto the same box that Orbital is running on, and refer to the taxi projects using file paths (rather than pulling from a git repository).

In cases like this, it’s often convenient to declare your projects in workspace.conf with relative paths (relative to the workspace.conf file), rather than absolute paths. We’ve fixed a number of bugs that previously made this very hit-and-miss. Now, it’s all hits.

​Pagination in query history

Previously, we only showed the first 100 results in query history. We now paginate these, so the full result set is available.

​Websockets timing out

We fixed a number of issues with websockets timing out - this was particularly noticeable if Orbital was deployed in AWS behind an ALB, where the ALB would terminate websocket connections after a period of inactivity. We’ve added ping/pong on the websockets to prevent this.

​Ability to remove projects pushed to Orbital

Often, a microservice will publish it’s project directly to Orbital. Previously, these weren’t removable using the UI. Now they are. That’s progress.

​Fixed cast expressions on a field

This used to throw an error. Now it doesn’t.

find {    long: Long by (Long) Foo}

​Projecting a scoped variable to a predefined array type

This also used to throw an error. We fixed that too.

find { FilmCatalog } as (films:Film[]) -> Movie[]

​Lots of bug fixes with Git based projects

We squashed lots of bugs related to workspaces that were pulled from git, and projects within workspaces that were pulled from git. This now behaves much much better.

​SQS Subscriber fixes

We have fixed an SQS subscription that might result in corresponding poll operations interrupted after the first successful poll. Additional configuration parameters to fine tune AWS SQS poll operations were also added, see the docs for the details.

​Changes to workspace.conf are now live reloaded

This bug manifested in lots of little, but rather annoying changes.

We now automatically update the UI after changes are made to the workspace.conf file (such as adding and removing projects).

​Other bug fixes:

• We’ve addressed issues with Logout not working as expected on Cognito
• Importing a Protobuf spec from the UI now works
• Saving a query no longer breaks the formatting
• Language server now reconnects automatically after disconnect
• Cancelling a streaming query from the query history view works again
• Fixed a bug where JSON results viewer would show type hints over and over and over
• Download query results as CSV works again
• Browser would crash when running queries returning large volumes of results
• A misconfigured workspace.conf file could prevent the server from starting

(The post Orbital 0.33 - Landing page insights, improved query editor, and simpler deployments. appeared first on Orbital Changelog.)

​Orbital 0.31.0 - “Alf” Edition

We’re excited to announce the release of Orbital 0.31.0 - with a large focus on helping new users feel comfortable — which reminded us of a certain ’80s friend. So, we present Orbital 0.31.0 - The “Alf” edition. 👽🛸🏡

​Highlights

• New connectors: MongoDB and Hazelcast
• New onboarding flow, and improved UX for projects and data sources
• Filtering streams of data
• Controlling the services called in a query

​MongoDB support (Preview)

We now support MongoDB as a datasource, including support for both querying and writing

​Hazelcast support (Preview)

Building on top of our support for Hazelcast as a cache, Hazelcast is now available as a data source, supporting reads, writes and streams.

Use a Hazelcast Map as a high speed data store, or use a Map as the basis for a Stream of data, giving you the best of both worlds.

​New onboarding experience

For those wanting to dip their toes into the world of Taxi and Orbital, we’ve built an onboarding flow which should help get you up to speed in no time! And remember, just like Alf trying to fit in with the Tanners, you might feel a bit out of place at first, but with our guidance, you’ll be navigating through like a pro in no time!

You’ll see this screen automatically when you don’t have any data sources declared, but you can also view it manually by going to /onboarding.

We welcome feedback in this area of the app, so please take it for a spin and let us know what you think.

​Improved UX for managing projects and data sources

Now that you’re familiar with adding projects and data sources after completing the onboarding steps, you’ll be happy to hear that those same project import and data source creation steps are available to you outside the onboarding flow. Consistency FTW!

We’ve completely reworked the Connections page, allowing a more streamlined view of all connections, and their related data sources.

If you want to add a new data source, then the same flow that was created for the onboarding flow is now used here as well. It’s like having Alf in charge of the kitchen - he sticks to his recipes with that good ‘ol fashioned consistency that we’re all about here at the house of Orbital.

​Sliding Sidebars

Ever needed a few more cm’s of screen space and thought, gee that sidebar is taking up a bunch of space? Well, now you can collapse it with a click of the mouse, and regain all that space you’ve been desperately hankering for. We’ll remember your preference as well, and restore things how you left them.

​Controlling services used in a query (preview)

By popular demand, one of our most requested features is the ability to control which services are called in a query. After all - if Alf taught us anything - given a universe of possibilities, a little navigation can save you landing in a whole world of trouble.

While designing this feature, we wanted to ensure that Taxi remains declarative - and find a balance between giving users control over which services are called, while remaining resilient and self-adapting as services evolve.

You can now limit a query to only call specified services, with the using keyword:

find { Film[] } as {  filmId : FilmId  reviews : ReviewScore}using { FilmsDb, NetflixApi::getReviews }

The list of allowed endpoints can be a mixture of services (FilmsDb), or even specific operations on services (NetflixApi::getReviews).

Similarly, you can allow Orbital to call any services except some, using the excluding keyword:

find { Film[] } as {  filmId : FilmId  reviews : ReviewScore}excluding { ImdbApi, RottenTomatoes::getReviews }

This too allows combining services and specific operations to exclude.

This feature is considered in preview, and the syntax may change, so we’re actively seeking feedback.

Please reach out to share your thoughts.

​Filtering a stream

We’ve added new support for filtering streams of data server-side (ie., on Orbital).

Imagine you have a Kafka stream of stock quotes, and you only want quotes for a specific symbol - this is now possible using .filterEach().

stream { StockQuotes.filterEach( Symbol -> Symbol == 'AAPL' ) }

​Http headers now visible

We now display HTTP headers in the Profiler view of queries

​Updates to Stream UX

The Endpoints page now shows the current status of individual streams.

The Stream Page allows enabling & disabling of individual streams.

​Streams now disabled by default

When a stream appears for the first time in the schema, it’s now disabled by default, and required manually enabling — for the first time only.

This is to prevent streams - which can be mutating - starting accidentally, because as Alf would say, ‘Hey, no one wants accidental mutations on their hands… or their planet!

​Streams now automatically updated

Whenever changes are found in a running streaming query, the stream is now automatically updated. Previously, this was buggy…Suboptimal.

​CVE Updates

This build bumps our internal dependencies, addressing the following CVE’s:

• CVE-2024-22257 Possible Broken Access Control in Spring Security With Direct Use of AuthenticatedVoter
• CVE-2024-22234 Broken Access Control in Spring Security With Direct Use of isFullyAuthenticated
• CVE-2024-22259 Spring Framework URL Parsing with Host Validation (2nd report)
• CVE-2024-22243 Spring Framework URL Parsing with Host Validation
• CVE-2023-52425 libexpat through 2.5.0 allows a denial of service

(The post 0.31 released - Hazelcast, MongoDb and a new onboarding experience appeared first on Orbital Changelog.)

​Orbital 0.30.0 - Full House Edition

We’re excited to announce the release of Orbital 0.30.0 - our “Full House” edition, because we got so distracted by Valentine’s Day last month that we didn’t manage to ship a release, making this one double-packed.

If you’re not familiar with Orbital, it’s a platform for automating integration between APIs, Databases, Message Brokers, Serverless Functions, and more. We have great stuff like API-spec driven data sources, self-repairing integration, automated lineage and more.

So, let’s take a look at what we’ve been working on for the past two months. It’s a full house jam packed with features and squashed bugs.

​Highlights

​MS SQL Server support

We’ve extended our family of supported databases to include MS SQL Server for comprehensive read and write operations.

So, it’s “DATABASES! DATABASES! DATABASES!”, sweaty armpits, and happy Microsoft shops.

Our docs explain all the details on how to connect to MSSQL, to get your Northwind blowing. (Get it? That’s a MSSQL sample database joke. If you know, you know.)

​SAML authentication support

Someone paid us a lot of money to build SAML. We didn’t wanna do it. But we did, and now it’s awesome. Learn more about how to configure SAML authentication in Orbital.

​mTLS Support

Mutual trust is a big theme in the Tanner household, and it’s something we can really get behind.

mTLS is now supported when calling HTTP(s) APIs. Read more about how to set up mTLS

​Mixed messages

Orbital will now read an XML message with a JSON message in the middle, or JSON with XML in it, or a CSV file with a JSON blog in that, or really anything inside of another thing, which is inside yet another thing. It’s the integration version of a Turducken.

For example, here’s some XML inside a JSON message:

{    "messageId" : "123",    "xmlRecord" : "<person><name>Jimmy</name></person>"}

Here’s the associated definition:

import com.orbitalhq.formats.Xmlmodel MyMessage {    messageId : MessageId inherits String    xmlRecord : Person}
@Xmlmodel Person {    name : PersonName inherits String}

​Using Jwt claims within a query

You can now pass the claims from a JWT token into Orbital so the claims can be used during query execution, and passed to upstream services.

Let’s look at a simple example where your JWT token has a key piece of information - the customers accountId. If you want to use these to connect with external REST services to run specific Orbital queries, the first thing to do is create a model that builds on Orbital’s basic JwtClaim model:

// Custom JwtClaim model with contactId and accountIdmodel CompanyXJwtClaim inherits JwtClaim {  accountId: AccountId // a claim present with the key accountId  // other claims omitted}

Adding this model to your system makes sure that accountId is available for Orbital when it runs queries.

For example, a service may require the users accountId from the JWT be passed in the URL:

// A service needs to use the current users accountId in the URL: service AccountService {   @HttpOperation(method = "GET",url = "/account/{accountId}")   operation getByAccountId(@PathVariable("accountId") accountId: AccountId): Account}

To make the users accountId available, we simply expose the JWT to the query:

query MyQuery ( jwt:CompanyXJwtClaim ) {   given { jwt }   find { Account }}

That’s it! The presented JWT is read and the accountId is used to invoice the getByAccountId operation.

​Errors on streaming messages

Previously, it was hard to see when things went wrong inside streaming queries, requiring tailing logs to debug issues.

Now, errors in streams are shown in a dedicated UI.

​Usability

​Filtering in the results table

Results returned from the server can be filtered client side in the query view:

​Language features

​Type checker

We’ve enabled Taxi’s type checker by default, to help surface errors in queries earlier.

For example, everyone in our office has made this mistake before:

find { Film[] } as {   cast: (Actor[]) -> { // because this is projecting an array...     name : ActorName   } // <--- ...this should be an array} // <-- so should this

Now, the compiler tells us what a mistake it was, so we can take a good long look at ourselves.

​Scoped Variables

When projecting, you sometimes need to hoist multiple variables into the scope. This is to make them available at the top level of a projection, without declaring them directly in the output.

For example, in the below example, we want to operate on a single item from an array of values, as well as the parent object.

However, we need both the objects in scope:

find { Film } as (Film, first(Actor[])) -> {  // two values declared in scope    title : Title // title comes from Film    starring : ActorName // ActorName comes from Actor}

Our query syntax now supports adding these additional variables into the query scope

​Compiler warnings when something should be declared closed

Marking a model as closed in TaxiQL indicates that the query engine should not attempt to build an instance if you ask for it.

Generally, this is the expected behaviour for things that a server returns.

For example:

// I want the Film object as returned from the server, not constructedmodel Film {   title : Title inherits String}
service Films {   operation findAllFilms():Film[]}

If writing a query like:

find { Film[] }

In the above example, you don’t want Orbital to try to construct a Film instance, you want one returned.

If you forget to mark Film as closed then the compiler will now warn you.

// That's better:closed model Film {   title : Title inherits String}

​Fixes

Here’s a big long list of things that we showed to people who asked why we hadn’t been to the pub this month.

To play us out, while you read through our bug list, here’s the Full House theme song.

• given clause with cast statement referencing parameter throws exception
• Server sends all responses as arrays
• Server sends arrays when response isn’t an array
• Response arrays of single item are incorrectly unwrapped
• Compiler not erroring when projecting array to non-array
• Can’t use params in call to table operation
• Live query view in history is broken
• Removing a project results in an orphaned view for a project that no longer exists
• Can’t onboard Kafka connections via UI
• Viewing Operations in Services view is borked
• Incorrect responsive layout in TypeViewer component
• Fix streaming results progress bar and record count
• Query History should not list active queries in the history panel, only in the “active” panel
• Copy as Curl breaks with single / double quote issues
• “undefined” entries showing in catalog
• Error not thrown when inner-projection mismatch on array properties
• Schema view shows all types in uppercase
• Duplicates listed in the intellisense
• Active queries in history is missing icons
• Docs missing from catalog page
• Tables in connection details need a minimum width
• Make checkboxes in app-model-attribute-tree-list readonly
• Disable project selector when adding connection
• Inlay type hints not shown in raw results
• Can’t authenticate to Confluent Cloud Kafka
• Format JSON responses in Response not working
• Ensure UI is in correct state when query is run
• Query History takes too long to load
• Projections with fields that are subtypes assign incorrectly
• Fields on anonymous types are not considered for population of graph queries
• Projection of a scoped top-level array fails
• Lineage for cached items can’t trace further back than the cache query
• Query Plan diagram is broken when cache is invoeld
• Services diagram renders shared attributes incorrectly
• StateStore is applied without the annotation
• Streaming queries are rewritten to join streams incorrectly
• Better UX when nothing is registered
• Starting a query with Apple+Enter / Ctrl+Enter shows incorrect time in ticker
• Http 204 responses are not persisted
• Language Server incorrectly reports some types as not defined
• connections.conf not resolving env variables from env.conf
• After saving a query with a streaming union type, can’t rerun another adhoc query with the same streaming union type
• SQL queries fail if the table name is different from the model name
• Profiler view doesn’t show all interactions

(The post 0.30 is Out - SQL Server, new authentication methods, and JSON inside XML inside a... duck? appeared first on Orbital Changelog.)

​Orbital 0.27.0 - The “Cheers” Edition 🍻

As the Orbital office farewells Dry January, we welcome back Friday drinks with a fresh release - 0.27.0.

Pull up a stool, grab your favorite beverage, and let’s toast to the new features, usability improvements, and fixes that are making Orbital 0.27.0 as cozy and welcoming as your favorite Boston bar.

​Features

​Retry Operations

Like Sam Malone behind the bar - or a Fraser reboot - we know the importance of second and third chances.

That’s why we’ve introduced @Retry annotations, ensuring that if at first you don’t succeed, requests can try, try again to connect and get your data flowing just right. Read more about it in the release announcement here, and the docs are available here

​Cache Eviction

There’s nothing worse than overstaying your welcome when it’s time to leave.

Orbital’s caches now support Cache headers, evicting data when it’s stale. Read more about it here, with the docs available here

​Better Connections for Kafka

Our Kafka connections now have more options than Frasier had patients - with full support for secure Kafka connections. Expect a seamless experience that keeps the data pouring in. More detail available in our docs

​Usability Stuff

​Better handling of query compilation errors

Pobody’s Nerfect, right?

Orbital now displays compilation errors in a slightly less antagonistic way. Read more here.

​Query history refreshes

Running a new query now refreshes the history view automatically, much like Norm Peterson’s beer mug. You’ll always have the latest information at your fingertips, no manual refresh needed.

​Loading bars

Our loading bars have received a makeover, becoming more informative and visually appealing. It’s the little details that make all the difference, ensuring you’re not left hanging while waiting for your data to appear.

​Fixes

• Projections of Nested Arrays: We’ve fixed the projection of nested arrays, ensuring that your data structures are handled with the care and precision of Cliff Clavin’s factoids—accurate, detailed, and meticulously organized.

• Nested Values in Discovery: Nested values are now correctly used as inputs to discovery, making your data exploration as smooth and effective as Woody Boyd’s charm. No more confusion or missteps.

• Cancelled Queries: Cancelled queries now appropriately show as “cancelled,” clearing up any confusion and ensuring you’re not left wondering what went wrong. It’s straightforward communication, just how Coach would have wanted it.

• Improved Performance of Loading Query History: We’ve supercharged the performance of loading your query history, making it faster than ever. It’s like getting your data served up by Sam himself—quick, efficient, and with a smile.

• Fix duplicates on child properties with same names: An unfortunate little gremlin meant in certain conditions child properties with the same name as a parent would get incorrect values.

So, here’s to Orbital 0.27.0 — Cheers to faster data, better performance, and a community where everyone is connected! 🍻

(The post 0.27 is Out - Retry, Cache Eviction and UX improvements appeared first on Orbital Changelog.)

​Expiry for Cached Queries

Orbital now honours HTTP cache headers on HTTP responses, when a cache is enabled for a query.

As described in Caching Orbital provides ability to cache query results with @Cache annotation:

@Cache(connection = "mycache")find { Film[] }

Let assume that you have a rest end point returning list of films:

service FilmServices {  @HttpOperation(method = "GET", url = "...")  operation listFilms():Film[]}

If your Rest operation returns Cache-Control header in its response, Orbital will take the max-age directive into account and expire the cached query result accordingly.

Here as an example response with Cache-Control header:

max-age=144004 will get Orbital to cache the Film list for 4 hours. After 4 hours, the items in the query cache will expire automatically.

​Grab the docs

Read more about caching in our docs

(The post Cache Eviction support appeared first on Orbital Changelog.)

​Retry Option for Http operations:

Let’s say you need to stitch Film data with reviews coming from an unreliable third party Rest Api:

service ReviewsApi {    @HttpOperation(method = "GET", url = "https://reviews/{id}")    operation getReviews(id: FilmId): FilmReview[]}

The third party REST API gives you intermittent HTTP 500s as it can’t cope with user requests at particular times during day.

To address such outages, you can now define a HttpRetry settings in Taxi for the operation.

Orbital Supports two HttpRetry policies:

​Retry Policy with Fixed Delay

Let say you want to Orbital to retry ‘getReviews’ operation when it responds with Http 500. You want Orbital to try the operation at most 10 times and wait 5 seconds between each retry. Here is how you can modify the taxi definition:

service ReviewsApi {    @HttpOperation(method = "GET", url = "https://reviews/{id}")    @HttpRetry(responseCode = [500], fixedRetryPolicy = @HttpFixedRetryPolicy(maxRetries = 10, retryDelay = 5))    operation getReviews(id: FilmId): FilmReview[]}

You can trigger the retry mechanism for multiple response codes as well, here is how you can modify previous Taxi definition to trigger the Retry mechanism when the remote service returns either Http 500 or Http 502

service ReviewsApi {    @HttpOperation(method = "GET", url = "https://reviews/{id}")    @HttpRetry(responseCode = [500, 502],       fixedRetryPolicy = @HttpFixedRetryPolicy(        maxRetries = 10,         retryDelay = 5    ))    operation getReviews(id: FilmId): FilmReview[]}

​Retry Policy with Exponential Delay

With exponential delay retry policy, Orbital will wait progressively longer intervals between consecutive retries:

service ReviewsApi {    @HttpOperation(method = "GET", url = "https://reviews/{id}")     @HttpRetry(responseCode = [500, 502], fixedRetryPolicy = @HttpExponentialRetryPolicy(maxRetries = 10, retryDelay = 5, jitter = 0.5))    operation getReviews(id: FilmId): FilmReview[]}

With the above definition, Orbital will try invoking the Rest at most 10 times in case of Http 500 or Http 502 errors.

However, the delay between retries will increase exponentially.

With a jitter value between 0 and 1, you add some randomness to the delay time by introducing a random delay, or “jitter”, to the next retry delay time. This ensures that the retries are not synchronous and reduces the likelihood of a retry storm.

Here’s how the table would look with exponential backoff with Jitter:

| Retry Attempt | Delay Time (seconds) | Jitter Range (seconds) | Actual Delay Time (seconds) | | ------------- | ---- -----------------|------------------------- |-----------------------------| | 1 | 1.0 | 0.5 | 1-0 - 1.5 | | 2 | 2.0 | 0.5 | 1-5 - 2.5 | | 3 | 4.0 | 0.5 | 3.5 – 4.5 | | 4 | 8.0 | 0.5 | 7.5 – 8.5 | | 5 | 16.0 | 0.5 | 15.5 – 16.5 |

​Summary

Http retries is out in 0.27. Read more about it over in our docs

(The post Http Retry Support appeared first on Orbital Changelog.)

Some UI/UX love for Orbital now, with a fine tuning of how compilation errors are being displayed on screen.

We’ll continue to improve the surfacing of messages like this throughout Orbital, allowing a more streamlined experience for users.

(The post Better query compilation errors appeared first on Orbital Changelog.)

Some users have been experiencing errors when running our docker images on Apple Silicon Macbook Pro’s (M1-3 et al).

The issue appears to be related to the base image we use for our Docker images - eclipse-temurin:alpine.

To address this, we’ve started producing extra images, based on Ubuntu Jammy.

Grab the images with the -jammy suffix, eg:

• 0.27.0-jammy
• next-jammy

These images aren’t suitable for production usage, as the Ubuntu Jammy base image contains significantly more security CVE’s than the -alpine images.

However, for local developer environments, they’re great - mainly because they don’t crash. Brilliant.

(The post Apple Silicon Friendly docker images available appeared first on Orbital Changelog.)

The @HttpHeader annotation now is now supported, for setting headers on HTTP requests.

For example:

service MyService {  @HttpOperation(method = "GET", url = "...")   // A fixed, static header  @HttpHeader(name = "Consumes", value = "application/json")  operation findPeople():Person[]
  // A header that's calculated  operation findPeople(     @HttpHeader(name = "If-Modified-Since") ifModifiedSince : Instant = addDays(now(),-7)  ):Person[]}

You can also pass header values in using the given {} clause in a query:

service MyService {  operation findPeople(     @HttpHeader(name = "Cache-Control", prefix = "max-age=") cacheMaxAge : CacheMaxAge  ):Person[]}
// which is then invoked as:given { maxAge : CacheMaxAge = 64000 } find { Person[] }

Read more about it in our docs

​Date math

The stdlib in Taxi has been expanded to add date math functions to the stdlib:

• addMinutes
• addDays
• addSeconds
• now
• parseDate

Read more about these in the Taxi docs

(The post Http Headers and Date Math appeared first on Orbital Changelog.)

Orbital now supports authentication and authorization with Azure AD (Entra) and AWS Cognito

This expands our OpenId Connect auth implementation (we already support Keycloak).

Full documentation with vendor-specific tutorials is now available in our sections on Authentication and Authorization.

(The post Auth with AWS and Azure appeared first on Orbital Changelog.)