Skip to main content

Release 2026.31.0

· 9 min read
meshcloud

Release period: 2026-07-29 to 2026-08-05

This release includes the following issues:

  • Fixed Internal Error When Deleting a Building Block Definition
  • Ownership Check Fix When Updating Platform Types via the meshObject API
  • meshBuildingBlockDefinition API Now Reports Who Created a Definition
  • Building Block Definition Approvals and Drift Detection in meshObject API
  • No Actions Are Offered for Deleted Building Blocks
  • Status Icons Now Sit Inline in Building Block Headers
  • Fix Building Block Definition Links on the Platform Builder Dashboard
  • Consistent Read Permissions and Filters in the meshObject API
  • Find Building Block Definitions by UUID in the Admin Area
  • Building Blocks Tab Is Now the Default in the Definition Control Plane
  • Aborting a Building Block Run Now Works Even if Its Runner Died
  • Building Block Detail View Now Shows Its Tenant or Workspace
  • Reactivate a Deactivated Landing Zone
  • Building Blocks Re-Run Automatically on User Group Membership Changes
  • Dedicated Artifact Upload for Building Block Runs

Ticket Details​

Fixed Internal Error When Deleting a Building Block Definition​

Audience: User

Description​

Deleting a building block definition failed with "An internal error occurred" when another definition had once depended on it. You saw this after you removed that dependency from a draft version to satisfy the conflict message that had blocked the deletion before. Removing the dependency made the conflict message disappear, but the deletion then failed with an internal error instead of succeeding.

Ownership Check Fix When Updating Platform Types via the meshObject API​

Audience: User

Description​

We fixed an authorization gap in the meshPlatformType API. When updating a platform type, we now check that you are allowed to manage the workspace that actually owns it, instead of the workspace named in the request body. Updating a platform type no longer accepts a request that names a different owning workspace than the current one. Because ownership cannot be transferred through this endpoint, such a request now fails with a clear error instead of silently ignoring the change. Deactivating and reactivating a platform type also shows up in the activity log now, so you can see who changed a platform type's state and when.

meshBuildingBlockDefinition API Now Reports Who Created a Definition​

Audience: User

Description​

The meshBuildingBlockDefinition API now tells you who created a building block definition, not just when in the status.lifecycle.created.author field. This works the same way status.lifecycle.markedForDeletion already did.

Building Block Definition Approvals and Drift Detection in meshObject API​

Audience: User

Description​

The meshBuildingBlockDefinition meshObject API now exposes the Run Approvals and Drift Detection & Schedule settings from the Policies tab. You can read and configure which run triggers require operator approval, and whether drift detection or drift reconciliation runs on a schedule, programmatically through the API.

No Actions Are Offered for Deleted Building Blocks​

Audience: User

Description​

Deleted Building Blocks no longer show an action in the Building Blocks list. Previously a deleted Building Block whose definition had a newer version still offered you an upgrade, even though nothing can be done to it anymore.

Status Icons Now Sit Inline in Building Block Headers​

Audience: User

Description​

We tidied up the headers of the Building Block and Building Block Run detail pages. The status icon now follows the name directly instead of sitting in its own column, so long names use the full width of the header and wrap naturally. On the run page, the run number and its status always stay together on one line, making it easier to see at a glance which run you are looking at and how it went.

Audience: User

Description​

On the Platform Builder dashboard, the "View all definitions" link on the Building Block Definitions card now takes you to the Definitions overview instead of the Building Blocks list. The "Add Building Block Definition" button shown when you have no definitions yet now opens the definition creation form directly.

Consistent Read Permissions and Filters in the meshObject API​

Audience: User

Description​

We unified how the meshObject API decides what your API key may read. Every list endpoint now returns the union of everything your key is entitled to see, and query parameters act purely as filters that narrow that result. A filter never widens what you can see and never decides access on its own, so filtering for something outside your permissions now returns an empty page instead of an error or a silently ignored filter.

How to use​

These endpoints behave differently than before:

meshBuildingBlock list: the unfiltered list now includes the Building Blocks created from a definition your workspace owns, even when another workspace consumes them. Previously you had to pass a managed filter to see them at all. The 'managedByWorkspaceIdentifier' and 'managedByDefinitionUuid' parameters still work, but they now only narrow the result within what your key may already see.

meshBuildingBlockRun list: the required 'buildingBlockUuid' parameter is now a pure filter. Passing the uuid of a Building Block you may not read returns an empty page instead of a 403, and an unknown uuid returns an empty page instead of a 404. Runs of an already deleted Building Block stay visible.

meshTenant list (v3 and v4): 'workspaceIdentifier' is now applied as you pass it. Previously we silently replaced it with your own Workspace whenever your key was not a platform admin key, so filtering for another Workspace returned your own Tenants. It now returns an empty page.

meshPaymentMethod list: 'workspaceIdentifier' is now applied as you pass it. Previously we ignored it for Workspace-scoped keys, so filtering for another Workspace returned your own Payment Methods. It now returns an empty page.

meshBuildingBlockRunner, meshLandingZone, meshPaymentMethod and meshPlatform list: a key that holds the list right but has no readable scope at all now receives an empty page instead of a 403.

If a client relied on any of the previous behaviours, pass the filters that describe what you actually want. What each of your keys may read has not changed - only how filters and errors interact with it. Read permissions on meshIntegration, meshBuildingBlockRunner, meshLandingZone, meshPlatform and meshTenantUsageReport are unchanged.

Find Building Block Definitions by UUID in the Admin Area​

Audience: User

Description​

You can now search the Building Block Definitions overview by UUID, not just by name. Previously the search box only matched names.

Building Blocks Tab Is Now the Default in the Definition Control Plane​

Audience: User

Description​

When you open a building block definition's control plane, the Building Blocks tab now opens first instead of the General tab. This gets you straight to the definition's provisioned building blocks, which is usually what you're looking for right after opening a definition.

Aborting a Building Block Run Now Works Even if Its Runner Died​

Audience: User

Description​

When you aborted a building block run that was already executing , meshStack waited for the runner executing it to confirm the abort. If that runner had already terminated in an unexcepted way, the confirmation never arrived and the run could appear stuck forever. We improved this edge case behavior to prevent runs getting stuck like this.

Building Block Detail View Now Shows Its Tenant or Workspace​

Audience: User

Description​

The Building Block detail view now tells you where a Building Block lives at a glance. Tenant-level Building Blocks show their tenant and workspace-level Building Blocks show their workspace, right next to the definition. As a partner, the tenant or workspace is a link that takes you straight there, so you no longer have to search for it.

Reactivate a Deactivated Landing Zone​

Audience: User

Description​

You can now reactivate a Landing Zone that was previously deactivated. Until now this was a one-way action. Reactivating makes the Landing Zone available for new Tenants again, so you no longer have to recreate one from scratch after deactivating it by mistake.

In meshPanel, deactivated Landing Zones now offer a "Reactivate Landing Zone" action. Because deactivating is now easily reversible, we also removed the confirmation prompt that used to appear before deactivating a Landing Zone.

Reactivating a Landing Zone requires permission to save Landing Zones, and deactivating one requires permission to delete them.

Building Blocks Re-Run Automatically on User Group Membership Changes​

Audience: User

Description​

Building Blocks that use a user permissions input now re-run automatically when the membership of a user group changes. Previously we only refreshed these Building Blocks when a role binding was added or removed, so adding or removing a user from a group that is already assigned to a Workspace or Project left the Building Block's user permissions stale until the next unrelated run. Now the affected Building Blocks reconcile right away.

Dedicated Artifact Upload for Building Block Runs​

Audience: User

Description​

Runners now upload the artifact a Building Block run produced - such as the plan a dry run creates for a Building Block change that needs approval - through a dedicated upload operation on the meshBuildingBlockRun API instead of embedding it in the run status update. Uploading the raw binary keeps large plans out of the status update payload, which makes run updates smaller and artifact handling more robust. Uploading is gated on its own permission, so you can grant a runner the ability to store artifacts without granting it broader run write access.

How to use​

We keep accepting artifacts embedded in run status updates for now, so existing runners continue to work and you don't have to change anything. Runners built against the current API should follow the artifact upload link on the run and upload the artifact before reporting the run as successful. If you issue API keys for your own runner, grant it the new artifact upload permission in the Building Block Runs permission group.