Skip to main content

Release 2026.32.0

· 8 min read
meshcloud

Release period: 2026-08-05 to 2026-08-10

This release includes the following issues:

  • See Which Building Block Manages an Object
  • Fixed Invisible Expiration Date Badge in Create Workspace Review
  • Removed the Building Block Deletion Approval Option
  • Filter the Marketplace for your Own Services
  • A Failed Preflight Marks the Building Block Unhealthy and Notifies You
  • Fix Sorting API Keys by Last Login Date and Expiry Date
  • Preflight Runs Now Link to the Apply Run They Triggered
  • Deleting a Building Block No Longer Stalls Behind a Pending Approval
  • Fix Some Building Blocks Got Stuck and Blocked New Runs
  • No More Arbitrary Runner Preselection in Building Block Definitions
  • Workspace Members Can Now Open Workspace-Level Building Blocks
  • Approve Multiple Building Blocks at Once

Ticket Details​

See Which Building Block Manages an Object​

Audience: User

Description​

Building Blocks that create other meshObjects are a common pattern: a starter kit deploys multiple objects into an application team's workspace, or a reference architecture deploys multiple objects into a platform team's workspace. When a building block or building block definition was created by another building block, the panel now shows a "managed by" link naming the building block that created the Building Block or Definition.

How to use​

This appears automatically, for existing objects as well as for new ones: in the cross-cutting Building Block list, on the "Building Blocks" tab of a Building Block Definition, and in the Building Block Definition overview.

Only Building Blocks you have access to are named. An object created by a Building Block in a Workspace you cannot see, or by one that has been deleted in the meantime, looks just like any other object.

Fixed Invisible Expiration Date Badge in Create Workspace Review​

Audience: User

Description​

We fixed a display bug on the "Review & Create" step of the Create Workspace wizard. The expiration date badge in the workspace access table rendered with white text on a white background, making it appear empty even though an expiration date was set. The badge now shows its color correctly, so you can see at a glance whether an access is expired, expiring soon, or not expiring.

Removed the Building Block Deletion Approval Option​

Audience: User

Description​

The "Building Block deletion" run approval option was already disabled and could not be selected. It never held a deletion run for review. We have no near-term plans to support it, so we removed it entirely: the toggle is gone from the run approvals of a building block definition, and the meshObject API no longer returns or accepts a deletion approval flag. Your other approval policies are unchanged. If approvals for deletion runs matter to you, please file a feature request and we will pick it up from there.

Filter the Marketplace for your Own Services​

Audience: User

Description​

Platform teams using the Platform Builder can now quickly filter the marketplace catalog in their Workspace Area to show only their own services. This makes it much quicker to find and review your own platforms and building block definitions among all the services offered in your meshStack.

How to use​

Open the marketplace in your workspace and switch the "All / My Services" filter next to the tag filter to "My Services". The filter is only available to workspaces with platform builder access.

A Failed Preflight Marks the Building Block Unhealthy and Notifies You​

Audience: User

Description​

When a Building Block run requires approval, meshStack first performs a preflight run that computes the planned changes for you to review. If that preflight fails, the change could not even be planned, so the Building Block's health status becomes "Failed" and you receive the same failure notification you get for a failed apply run. The Building Block therefore shows up in the health filter of the Building Blocks list, where you would expect it.

Plain dry runs behave differently and are unchanged: they only inspect resources and change nothing, so they never affect the health status and never trigger a notification.

Status, health status and the suggested action of a Building Block are now always derived from the same run, so they can no longer contradict each other. In particular, a preflight that succeeded and found changes still to apply has planned rather than applied them: it leaves all three fields showing the last run that actually changed something. A failed Building Block therefore keeps asking you to review its errors instead of offering "Review drift" until the follow-up run takes over.

Fix Sorting API Keys by Last Login Date and Expiry Date​

Audience: User

Description​

Clicking the "Last Login On" or "Expires On" column headers in the API Keys overview showed an error instead of sorting the list. We fixed this, so sorting by last login date and expiry date now works as expected, making it easier to spot API Keys that haven't been used in a while or are about to expire.

Audience: User

Description​

When a preflight run detects changes, it triggers a follow-up apply run that reuses the terraform plan the preflight produced. The preflight run now tells you that this happened and links straight to that apply run, so you no longer have to hunt for it in the run list. The apply run already pointed back at its preflight, and the two callouts now use clearly different colors, icons and wording, so you can always tell which of the two runs you are looking at.

How to use​

Open a preflight run of a building block. If it triggered a follow-up apply run, a callout at the top of the run links to it. The callout appears as soon as the follow-up run has been created, which can be a moment after the preflight finishes.

Deleting a Building Block No Longer Stalls Behind a Pending Approval​

Audience: User

Description​

We fixed an edge case where deleting a Building Block could hang indefinitely if one of its runs was still waiting for approval. Deletion runs now always start without an approval gate, so they are queued right away.

Fix Some Building Blocks Got Stuck and Blocked New Runs​

Audience: User

Description​

A Building Block could get stuck looking busy. Its status stayed "Pending" even though none of its runs were still running, which we saw after a deletion run failed, for example. The Trigger Run button stayed disabled and you could neither retry nor delete the block. A Building Block's status now follows its runs more closely, so it can no longer disagree with what actually happened.

No More Arbitrary Runner Preselection in Building Block Definitions​

Audience: User

Description​

When you create a building block definition and several building block runners are available, we no longer preselect one for you. Previously we picked the first shared runner we found, which looked arbitrary and made it easy to save a definition against a runner you never intended to use. This was most noticeable when importing a definition from the meshStack Hub, where the runner was already filled in before you had a chance to look at it.

Workspace Members Can Now Open Workspace-Level Building Blocks​

Audience: User

Description​

As a workspace member, your building block list already included the workspace-level building blocks of your workspace, but opening one of them failed with a "no permission" error. We fixed this: you can now open these building blocks and follow through to their details, runs and run steps, just like the ones in your own projects.

Approve Multiple Building Blocks at Once​

Audience: User

Description​

You can now approve many building blocks from the Building Block list instead of opening each run on its own. Select the rows you want and choose Approve from the Actions menu. Building blocks in the selection that are not awaiting approval are simply left alone, so you no longer have to prune your selection first.

How to use​

The confirmation tells you how many of the selected building blocks are actually awaiting approval, and a summary afterwards reports the outcome for each one: approved, not awaiting approval, or skipped because its plan changed.

Every approval stays bound to the plan you saw in the list: if a building block was re-planned in the meantime, we do not approve it and ask you to review the new plan instead. Selecting all building blocks matching the current filter stays within that filter and approves only the ones awaiting approval, each with the changes currently planned for it, which you have not reviewed individually.