Skip to main content

Release 2026.24.0

· 11 min read
meshcloud

Release period: 2026-06-03 to 2026-06-11

This release includes the following issues:

  • Fixed Metering Pipeline Stalling on Newly Created Resources
  • Clearing platform Access Information via the v2 meshObject API Now Works
  • Fix Building Block Name Not Updating When Changing Version or Tenant
  • Building Block Dry Runs No Longer Mutate State
  • Configure Run Control for Building Block Definitions via a Policies Tab
  • Unified Building Block Runner For All Implementation Types
  • Clearer API Docs for Sensitive Building Block Inputs
  • Released Building Block Definition Versions Are No Longer Changed by Later Edits
  • Clearer Error Messages for Invalid Input Values in API Requests
  • Building Block status output documentation now reflects the correct output types
  • Fix Long Word Overflow in Communication Center Notifications
  • Fix Broken Building Block Configuration Display During Project Creation
  • AWS Tenants Now Show Current Users When Using External IAM
  • Building Block Run Detail No Longer Shows a Redundant Back Button
  • Trigger Info Now Shown on Building Block Run Details
  • Building Block Details Breadcrumbs Now Link Correctly
  • Sort Building Blocks by Definition or Last Run Date
  • meshBuildingBlock API Now Supports Dry Runs via trigger-run
  • Fixed Missing Trigger Attribution for Building Block Runs
  • meshBuildingBlock Trigger Run Endpoint Renamed
  • Correct Setup Instructions for All Runner Types
  • Building Block Status Now Distinguishes Purged from Deleted Blocks
  • Improved Building Block Run Events
  • Building Block Events Now Show What Inputs Changed
  • Newly Created Runners Now Show Correct Connection Status
  • Improved Icons and Labels for Building Block Run Triggers
  • Breadcrumb Navigation Added to the Admin Area

Ticket Details​

Fixed Metering Pipeline Stalling on Newly Created Resources​

Audience: User

Description​

We fixed a bug that could permanently stall the processing of collected usage data for a platform as soon as a newly created resource (e.g. a new Pod or Building Block) appeared. Affected platforms showed a failed metering status and produced missing or outdated usage data.

How to use​

No action is required. After upgrading, the stalled processing resumes automatically and catches up on all collected usage data that has not expired yet.

Clearing platform Access Information via the v2 meshObject API Now Works​

Audience: User

Description​

We fixed a bug in the v2 meshObject API where setting spec.accessInformation to null in a meshPlatform PUT request had no effect. The previous value was silently preserved, which caused the Terraform provider to report an inconsistent result after apply. You can now reliably clear a platform's access information by omitting the field or setting it to null.

Fix Building Block Name Not Updating When Changing Version or Tenant​

Audience: User

Description​

We fixed a bug in the building block creation dialog where the auto-suggested name did not update when you changed the version or tenant selection. The name now correctly reacts to these input changes as long as you have not manually renamed the building block.

Building Block Dry Runs No Longer Mutate State​

Audience: User

Description​

We fixed a bug where building block dry runs were incorrectly changing the building block's status. Dry runs are now read-only with respect to the building block's status and outputs. They no longer incorrectly reset a succeeded/failed building block to pending or overwrite its outputs.

Configure Run Control for Building Block Definitions via a Policies Tab​

Audience: User

Description​

Building block definitions now have a dedicated Policies tab in their control plane view. You can use it to configure Run Control, the setting that controls who can review technical building block run logs and manually trigger new runs, independently of the definition's general info.

Unified Building Block Runner For All Implementation Types​

Audience: User

Description​

We consolidated the five separate system-managed runners (one per implementation type: Manual, Terraform, GitHub Workflow, GitLab Pipeline, Azure DevOps Pipeline) into a single run-controller runner that handles all implementation types. You will now see one managed runner in your runner overview instead of five.

The runner overview filter has also been improved: filtering by a specific implementation type (e.g. "Manual") now shows only runners explicitly configured for that type. A new "All" filter option lets you explicitly search for runners that support all implementation types, like the run-controller.

Existing Building Block Definitions that previously used one of the five separate system-managed runners have been automatically migrated to the new unified runner and will continue to work without any changes.

For Users of the API: If you are using the meshObject Building Block Definition Version or Integration API to reference runners, please update your integrations to reference the new unified run-controller runner UUID: 98520496-627d-43e6-82da-ce499179ff3f. If you reference a legacy runner UUID in the runnerRef object, the API will throw a 409 HTTP error explaining the upgrade. If you use the latest version of the meshStack Terraform provider you have no issues as this migration will automatically be handled in there.

Below is the full list of UUIDs so you can check and update your implementation:

  • Run-Controller (new & supports all implementation types): 98520496-627d-43e6-82da-ce499179ff3f
  • Manual (legacy): 46b7c17a-61f0-4062-9601-5785e60ce11f
  • Terraform (legacy): 66ddc814-1e69-4dad-b5f1-3a5bce51c01f
  • GitHub Workflow (legacy): dc8c57a1-823f-4e96-8582-0275fa27dc7b
  • GitLab Pipeline (legacy): f4f4402b-f54d-4ab9-93ae-c07e997041e9
  • Azure DevOps Pipeline (legacy): 05cfa85f-2818-4bdd-b193-620e0187d7de

Clearer API Docs for Sensitive Building Block Inputs​

Audience: User

Description​

The building block API documentation now clearly explains how to provide sensitive inputs in POST and PUT requests. When a building block has a sensitive input, you need to supply either a plaintext or a hash instead of a plain string value.

Released Building Block Definition Versions Are No Longer Changed by Later Edits​

Audience: User

Description​

We fixed a bug where creating and editing a new draft version of a Building Block Definition could retroactively change the implementation of the released version it was based on. Released versions now stay immutable.

Clearer Error Messages for Invalid Input Values in API Requests​

Audience: User

Description​

When you send an API request with an invalid value for a field - for example, a value that isn't one of the accepted options - the error response now tells you exactly which field caused the problem and lists the accepted values. This makes it easier to spot and fix mistakes without guessing.

Building Block status output documentation now reflects the correct output types​

Audience: User

Description​

The API documentation for building block status outputs now correctly lists only the valid output types: STRING, CODE, INTEGER, BOOLEAN, and FILE.

Fix Long Word Overflow in Communication Center Notifications​

Audience: User

Description​

Long words (especially URLs) in communication center notifications used to break out of their container, making the email layout look broken. We fixed this both in the delivered email and in the Preview tab of the "Create New Communication" modal, so what you see in the preview now matches what recipients receive.

Fix Broken Building Block Configuration Display During Project Creation​

Audience: User

Description​

We fixed a bug where the building block configuration was not rendering correctly during project creation when using a recommended building block. Descriptions and other markdown content in the configuration were not displayed properly.

AWS Tenants Now Show Current Users When Using External IAM​

Audience: User

Description​

When you use an AWS platform with an external permission management system (such as a Landing Zone Lambda or AVM) instead of AWS IAM Identity Center, meshStack now correctly shows all desired users as current users on your tenant. Previously, the current user list would always appear empty for these platforms.

Building Block Run Detail No Longer Shows a Redundant Back Button​

Audience: User

Description​

We removed the "Go back to all Runs" button from the building block run detail page. The breadcrumbs at the top of the page already provide the same navigation, so the button was redundant.

Trigger Info Now Shown on Building Block Run Details​

Audience: User

Description​

The building block run details page now shows why a run was triggered and who initiated it. You can hover the help icon next to the "Triggered" timestamp to see the trigger reason and the author.

Audience: User

Description​

We fixed a bug in the Platform Builder where breadcrumbs on building block detail pages were linking to building block definitions instead of the building block itself. The breadcrumbs now correctly reflect your navigation path and link to the right pages, making it easier to navigate back to where you came from.

Sort Building Blocks by Definition or Last Run Date​

Audience: User

Description​

You can now choose how building blocks are ordered in the building block table. In addition to the default sorting by the most recent run date to quickly find the blocks that ran last, you can switch to sorting by the building block definition. We remember your chosen sort mode in your user settings, so it stays the same across sessions and devices.

meshBuildingBlock API Now Supports Dry Runs via trigger-run​

Audience: User

Description​

You can now trigger a dry run for an existing building block via the meshBuildingBlock API by including dryRun: true in the trigger-run request body. Dry runs detect what changes would be applied without actually executing them. Currently only OpenTofu building blocks support dry runs; support for more implementation types may follow in the future.

Fixed Missing Trigger Attribution for Building Block Runs​

Audience: User

Description​

In rare cases, a building block run could show no trigger attribution - making it unclear who or what started the run. We fixed this so the trigger is now always correctly recorded and visible.

meshBuildingBlock Trigger Run Endpoint Renamed​

Audience: User

Description​

We renamed the action endpoint for triggering a building block run from retrigger-run to trigger-run in the v2-preview API.

Correct Setup Instructions for All Runner Types​

Audience: User

Description​

The runner detail page previously showed Terraform-specific setup instructions for all runner types. We fixed this so that GitHub Workflow, GitLab Pipeline, Azure DevOps Pipeline, and Manual runners now display the correct runner-config.yml format and Docker start command for their runner type.

Building Block Status Now Distinguishes Purged from Deleted Blocks​

Audience: User

Description​

When a Building Block is purged we now show a dedicated "Purged" status instead of the generic "Deleted" status. This makes it clear at a glance how a Building Block reached its final state.

Improved Building Block Run Events​

Audience: User

Description​

We replaced the "Building Block Run Executed" event with two more precise events: "Building Block Run Created" (when a run first appears) and "Building Block Run Completed" (when a run reaches a terminal state such as succeeded or failed). Both events now show who triggered the run and why. Previously these always appeared as triggered by the system. Intermediate status change events (e.g. when a run moved to In Progress) are no longer written as they do not provide any relevant audit information.

The old "Building Block Run Requested" event was a catch-all covering many trigger reasons. These now have dedicated events per action, e.g. "Building Block Inputs Updated" for input changes.

How to use​

Open the event log for any building block to see the updated run events. Each "Run Completed" event shows the actual triggering author (user, API key, or system) and includes a human-readable trigger reason such as "it was manually triggered" or "a dependency's output changed".

If you filter the event log API by title, update your filters:

  • Replace "Building Block Run Executed" with "Building Block Run Created" or "Building Block Run Completed"
  • Replace "Building Block Run Requested" with "Building Block Run Triggered" for manual trigger events

Building Block Events Now Show What Inputs Changed​

Audience: User

Description​

When a building block's inputs are updated or a building block is upgraded to a new version, the event log now shows exactly what changed. You can see the previous and new values for each modified input side by side, making it easy to understand what triggered a run and what was affected.

Sensitive inputs are automatically masked as <hidden> to keep secrets out of the event log.

Newly Created Runners Now Show Correct Connection Status​

Audience: User

Description​

When you created a new building block runner, a regression caused it to immediately showed as "active" (as if it had already connected), even before the runner had a chance to poll meshStack for the first time. We fixed this: a newly created runner now correctly shows as "pending" until it establishes its first connection.

Improved Icons and Labels for Building Block Run Triggers​

Audience: User

Description​

Building block run trigger reasons now show clearer, context-specific icons and consistent past-tense labels.

Audience: User

Description​

We added breadcrumb navigation to the Admin Area. You can now see exactly where you are within the administration screens and quickly jump back to any parent page - for example from a workspace's quota settings back to the workspaces list - without relying on the browser's back button.