Skip to main content

Release 2026.39.0

· 14 min read
meshcloud

Release period: 2026-09-17 to 2026-09-23

This release includes the following issues:

  • List Building Block Runs After an Input Was Removed
  • Umlauts in API Error Messages Now Show Correctly in Terraform
  • Listing Bindings for Another Workspace Now Fails Instead of Returning Yours
  • Read the Fields of a JSON Input in an Input Condition
  • Managed Badge Stays on Building Blocks While Their Run Refreshes
  • Reordered Building Block Definition Inputs Stay in Place After Saving
  • Building Block Edit Form Shows Only the Inputs a Person Fills In
  • Importing a Building Block From the meshStack Hub Works Again
  • Only Platform Teams Can Purge a Building Block
  • Clearer Error When Building Blocks Block a Workspace Deletion
  • Project Binding APIs Now Carry the Expiry Date
  • Retry a Failed Deletion From the Building Block Bulk Actions
  • Lists Now Follow a Sort or Filter You Change While They Load
  • Correct Scoping of Project Tag Edit Permissions
  • Fixed Intermittent Errors When Releasing a Building Block Definition Version
  • Building Block Definitions Can Support Individual Platforms Through the API
  • Building Blocks Now Open on the Overview Tab
  • Unknown Supported Platforms Are Now Rejected
  • Create and Delete Audit Events Now Show the Full Object
  • List Only the Project Bindings Via API That Are Still in Effect
  • Building Block Runs Now Report When They Were Created
  • Building Blocks Now React When a Project Role Expires
  • Queued Building Block Runs Wait for an Input That Turns Required
  • Locked Building Block Inputs Stay Locked When They Appear

Ticket Details​

List Building Block Runs After an Input Was Removed​

Audience: User

Description​

You can list the runs of a building block again after its building block definition no longer has one of the inputs an older run used. This happened when you upgraded the building block to a version without that input, or removed the input from a draft version. The API then answered with an internal error. Older runs now still show the input they ran with.

Umlauts in API Error Messages Now Show Correctly in Terraform​

Audience: User

Description​

When the meshStack API rejected a request, for example because a policy was violated, it sent the error message in the ISO-8859-1 encoding. Terraform, the meshStack CLI and most scripts read it as UTF-8, so characters like umlauts turned into a question mark, for example in a policy's "how to fix" text shown in a failed Building Block run. We now send all API error messages as UTF-8, so you see the text exactly as it was written.

Building Block runs that failed before this fix keep the question mark in their logs, as the character was already lost when the run stored them.

Listing Bindings for Another Workspace Now Fails Instead of Returning Yours​

Audience: User

Description​

When you listed workspace role bindings or service instances with an API key that is scoped to a single workspace and asked for a different workspace, we quietly ignored your filter and answered with your own workspace's data. You had no way to tell the two apart, so the result could end up filed under the wrong workspace. We now reject such a request with 403 Forbidden, so you always know which workspace the data you get back belongs to.

Listing workspace user and group bindings also works with API keys, not only with API users. The API root did not offer you the links to these two lists when you authenticated with an API key, and our documentation said the lists were reserved for API users. Both are fixed: an API key with the permission to list workspace role bindings now discovers the lists from the API root, and the documentation names the permissions each list needs.

How to use​

Nothing changes as long as you omit the workspace filter or name your own workspace. An API key with the admin permission to list workspace role bindings in any workspace can still filter by any workspace.

Read the Fields of a JSON Input in an Input Condition​

Audience: User

Description​

A condition on a building block input can now look inside a JSON input. Written on its own, input.profile is still the JSON text, as before. Written with a dot after it, it is the object its JSON schema describes, so you write input.profile.tier == "gold" or input.profile.address.city != "" and reach nested objects, lists and numbers directly.

See our Building Block documentation for what a condition can read and the expressions it supports: https://docs.meshcloud.io/concepts/building-block/#supported-expressions

Managed Badge Stays on Building Blocks While Their Run Refreshes​

Audience: User

Description​

When the Building Blocks list refreshes a building block with a running run, the building block now keeps its Managed badge and the "managed by" link. Before, both disappeared from the refreshed rows until you reloaded the page, so you could no longer see which building block manages it.

Reordered Building Block Definition Inputs Stay in Place After Saving​

Audience: User

Description​

When you changed the order of the inputs or outputs of a Building Block Definition and saved, the list jumped back to the old order until you reloaded the page. The saved order was correct all along, only the page did not show it. The list now keeps the order you saved.

Building Block Edit Form Shows Only the Inputs a Person Fills In​

Audience: User

Description​

When you edit the inputs of a Building Block, the form now asks only about the inputs a person supplies: your own inputs and, for the platform team, the operator inputs. Static values, environment variables and the values meshStack assigns itself are no longer mixed into the form. They stay available below it behind "Show all inputs".

This also fixes a bug in the new Building Block experience. An app team saw the platform operator's inputs as editable and required, so an empty operator input blocked the form and a filled one failed to save. These inputs are read-only for app teams again.

How to use​

Open a Building Block, go to Settings and then Inputs. Change what you may change and choose "Save & Run". Choose "Show all inputs" to see the inputs the form does not ask about.

Importing a Building Block From the meshStack Hub Works Again​

Audience: User

Description​

When you import a building block definition from the meshStack Hub, every input now keeps the assignment type the module declares. Static values, tag values, user permissions and the identifiers meshStack injects no longer all arrive as user input that an application team would have to fill in. Name, description and readme come through as well, including the ones a module lets you override. A module that only offers some of its inputs when the feature behind them is enabled now arrives with all of them, instead of with none. You no longer have to correct each input by hand after the import.

Only Platform Teams Can Purge a Building Block​

Audience: User

Description​

Purging a building block removes it from meshStack without cleaning up the resources it created. With the Workspace Building Block Control Plane feature preview added in the last release, application teams could see and use this option. They no longer can: purging is reserved for platform administrators and the platform team that owns the building block definition.

Application teams still delete their building blocks as before, and a definition set to delete by purging keeps behaving exactly that way.

Clearer Error When Building Blocks Block a Workspace Deletion​

Audience: User

Description​

When you delete a workspace that still has building blocks, we now tell you which ones are in the way and what to do about them.

Project Binding APIs Now Carry the Expiry Date​

Audience: User

Description​

The meshProjectUserBinding and meshProjectGroupBinding APIs now return the date on which a project role expires, and you can set one when you create a binding. This means you can use the API as the source of truth for who currently holds which project role, for example to reconcile project roles into your identity provider groups.

How to use​

Send an expiryDate with a binding to have the role revoked after that date, or leave it out for a binding that never expires. A binding stays valid through the end of its expiry date, and a date in the past is rejected. If you manage your bindings declaratively, changing the date in your definition moves the expiry date of the existing binding, and re-applying an unchanged definition stays a no-op even once the date has passed.

Retry a Failed Deletion From the Building Block Bulk Actions​

Audience: User

Description​

When a building block's deletion run fails, the block stays queued for deletion so you can try again. Until now the bulk Run and bulk Delete actions quietly skipped exactly those blocks: you got a success message, but no run was ever started. You had to open each block and retry it on its own.

Both bulk actions now act on a block whose deletion run has finished, so you can retry a stuck deletion for many blocks at once. A block whose deletion is still running is left alone, as before.

How to use​

Select the affected building blocks in the Building Blocks list and choose Run or Delete as usual.

Lists Now Follow a Sort or Filter You Change While They Load​

Audience: User

Description​

When you changed the sort mode or a filter on a list before it had finished loading, your change was lost: the list kept the rows of the previous query while the controls above it already showed your new choice. On the Building Block list this showed up as a list that says it is sorted by last run without being sorted that way, which is why it only ever happened right after opening the page. Lists now stop the load that is still running and fetch what you asked for instead, so your choice takes effect right away.

Correct Scoping of Project Tag Edit Permissions​

Audience: User

Description​

If you belong to several workspaces, your permissions in one workspace could reach projects in another. Though this was never possible from the panel, a user who managed workspace A and was also a plain member of workspace B could edit the tags of workspace B's projects without holding any management role there.

Fixed Intermittent Errors When Releasing a Building Block Definition Version​

Audience: User

Description​

Releasing a version of a building block definition could fail with a server error. The failure was rare and looked random, and retrying the release usually worked. We fixed the cause, so your release now goes through on the first attempt.

We also hold back the marketplace publication emails until the release is actually stored. Before, we notified reviewers and workspace managers about a publication even when the release itself had failed.

Building Block Definitions Can Support Individual Platforms Through the API​

Audience: User

Description​

When you manage a building block definition through our API, its supported platforms can now name individual platforms, not only whole platform types, so you can offer a definition on one platform instead of on every platform of its type. Naming a platform type still means every platform of that type, and you can mix both in one definition. If you manage definitions with our Terraform provider, upgrade it to the latest version before you upgrade meshStack.

Building Blocks Now Open on the Overview Tab​

Audience: User

Description​

When you open a building block in the admin or service management areas, you now land on its Overview tab instead of the Runs tab. The Overview shows the status, the inputs and outputs, and the latest run on one page, so you get the whole picture before you dig into a single run.

When we introduced the Overview tab, we deliberately kept Runs as the landing tab so that nothing moved under you from one release to the next. The Overview has proven the better starting point, so it now takes over as the default.

Unknown Supported Platforms Are Now Rejected​

Audience: User

Description​

When you create or update a building block definition, we now check every entry of its supported platforms. If you name a platform type that does not exist, you get an error instead of a definition that silently supports fewer platform types than you asked for.

Create and Delete Audit Events Now Show the Full Object​

Audience: User

Description​

When you create or delete a workspace, project, platform or tenant, the audit event now records the whole object in the same structure the meshObject API uses, and the event log shows it as the structured diff you already know from landing zones. You see the tags a workspace or project carried, and a deleted platform also records the connection configuration it used, as long as whoever deletes it may read that configuration. These events now carry the object instead of the handful of fields they listed before, so if you read their content through the meshEventLogs API, expect the new structure. The role assignments a workspace or project started with are no longer part of its create event. They now appear as their own "Workspace User Role Added" and "Project User Role Added" events, the same ones you already get when someone is assigned later, and the tenants a project started with each have their own "Tenant Created" event.

List Only the Project Bindings Via API That Are Still in Effect​

Audience: User

Description​

When you list project user bindings or project group bindings via the meshObject API, you can now leave out the ones whose expiry date has passed.

How to use​

Add excludeExpired=true to your request to get back only the bindings that are still in effect. A binding stays in effect through the end of its expiry date, and a binding without an expiry date is never left out. Every binding keeps showing up when the parameter is left out, so nothing changes for your existing integrations.

Building Block Runs Now Report When They Were Created​

Audience: User

Description​

The building block run API now tells you when each run was created. Until now the API carried no timestamp at all, so lining runs up against your own records meant reading the times off the run list in the panel, or asking us. Note that this is when the run was created, not when it started to execute. A run that waits for an input, a parent building block or an approval is created long before it runs.

Building Blocks Now React When a Project Role Expires​

Audience: User

Description​

When a user's role on a project reaches its expiry date, we now ask the building blocks of that workspace to reconcile, so a building block using the "User Permissions" input picks up the change. Only blocks whose inputs really changed run; the others stay untouched. Until now nothing asked them at all, so such a block kept provisioning access for the expired user until an unrelated change happened to trigger the next run, which could be weeks later.

Queued Building Block Runs Wait for an Input That Turns Required​

Audience: User

Description​

A run that is already queued now waits when its building block ends up needing an input it has no value for. This happens above all when a condition starts to hold and turns that input into a required one. Before, such a run could reach your runner without the value and execute with the input missing.

Locked Building Block Inputs Stay Locked When They Appear​

Audience: User

Description​

An input whose provider does not allow you to change it now stays read-only in every case, including when it carries a condition and only appears once that condition holds. Before, such an input became editable the moment it appeared, and saving your change was rejected.