Mitigate the impact of version 2026.8 breaking changes

Copy link

• No reinstall or redeployment is needed when these changes ship. They will apply as standard database migrations during your normal automation orchestrator upgrade.
• There is no supported downgrade path once a version containing one of these changes has been applied. If you may need to revert, back up your PostgreSQL database before upgrading. Automation orchestrator does not manage or back up your database for you.
• Because these changes make delete operations remove more data than before, review the contents of a workflow, project, user, or group before deleting it. There is no restore capability for any of these resource types.
• Export or back up any resources you might need before upgrading, because resource deletion is now permanent.

Projects: deleting a project permanently deletes everything in the project (2026.8)

Copy link

In a future release, deleting a project permanently deletes all of its contents, including workflows, workflow versions, execution history, and credentials. Today, project deletion already removes most of this, but going forward the behavior is fully consistent. A project and its contents are not recoverable after a project is deleted.

Workaround: Before deleting a project, make sure nothing inside it needs to be kept. Export any workflows you want to preserve, and move or recreate any credentials you still need elsewhere first.

Users and groups: deleting a user or group permanently removes more associated data (2026.8)

Copy link

In a future release, deleting a user permanently removes that user's data. This includes group memberships, linked identities, active sessions, approval-approver associations, API token configuration, and usage records. Deleting a group permanently removes its memberships, identity-provider group mappings, and approval-approver associations. In both cases, role assignments tied to the deleted user or group are also removed. If a deleted user had previously created a group, the group itself is not deleted. Only the recorded creator is cleared.

Workaround: Before deleting a user or group, confirm that any role assignments, approvals, or memberships tied to them do not need to be preserved elsewhere. They are not recoverable once the deletion completes.

Approvals: approval detail responses expose full downstream step parameters, including script code (2026.8)

Copy link

Issue: GET /approvals/{id} returns the full parameters of the downstream workflow steps and approval gates. These parameters, including script step code, appear in the next_step_approved and next_step_rejected fields.

This response includes more detail than an approver needs to make a decision. An approver might not have permission to view the workflow's contents, and step parameters can contain proprietary logic or sensitive values.

Possible breaking change: If this is fixed by removing parameters from next_step_approved and next_step_rejected, any integration reading those fields (for example, to display script code to approvers) stops receiving that data. This would not be an OpenAPI schema change (the field was never a declared property). However, it would remove something the response currently and consistently includes.

Workaround: None yet. No change has shipped. If you depend on next_step_approved.parameters or next_step_rejected.parameters, be prepared for those fields to disappear if this is addressed.

Approvals: unrecognized query parameters on list endpoints (2026.8)

Copy link

Issue: A report claims that unrecognized or misspelled query parameters on GET /approvals (and similar list endpoints) silently return zero results instead of being rejected or ignored. This makes it impossible to distinguish a genuinely empty result set from a malformed request. This behavior was not reproducible against the current codebase. The issue is being tracked in case it resurfaces in a specific deployed version and leads to an issue before the fix is released. Unrecognized filter fields and invalid filter values already return a 422 validation error today.

Possible breaking change: If a fix is still needed, the outcome depends on the approach. Rejecting unrecognized parameters with a 422 turns a previously successful request into an error. This would be a breaking change for any caller currently sending unrecognized parameters. Silently ignoring unrecognized parameters and applying only recognized filters would not be breaking.

Workaround: Not applicable, no defect currently confirmed. If you encounter unexpected empty results tied to a query parameter, check the parameter name and value against the documented filters for that endpoint. For approvals the documented filters include status and execution_id.

Mitigate the impact of version 2026.8.1788958058 breaking changes

Copy link

• No reinstall or redeployment is needed. These changes are delivered through the normal automation orchestrator upgrade process. The operator applies database migrations automatically during upgrade.
• Automation orchestrator database migrations do not provide a supported downgrade path. If you might need to revert the upgrade, create and verify your own PostgreSQL backup before upgrading.
• After upgrading, review service-account credential lifetime settings, replace calls to the removed /health endpoint, and update API clients for the response-field and status-code changes described above.
• Before deleting a workflow or credential, verify that the associated history or integration references are no longer needed.

Service accounts: credential maximum lifetime moved to a runtime setting (2026.8.1788958058)

Copy link

The maximum lifetime for service-account credentials is no longer the APP_SA_CREDENTIAL_MAX_LIFETIME_DAYS environment variable. It is now the service_accounts.credential_max_lifetime_days runtime setting. This value is not configured on the AutomationOrchestrator custom resource.

Mitigation: After upgrade, set it in automation orchestrator: System Administration > Settings > Authentication > Credential maximum lifetime (days). You can also set it through the Settings API. Changes apply on the next credential create or rotate and do not require a restart.

A previous environment variable value is not migrated. If you customized APP_SA_CREDENTIAL_MAX_LIFETIME_DAYS, copy that number into Settings before creating or rotating credentials. If you do not change the setting, the default is 180 days. For more information, see Service account authentication error reference.

Workflows: unsupported template expression scopes are now rejected (2026.8.1788958058)

Copy link

The ${input.*}, ${inputs.*}, and ${variables.*} expressions are no longer treated as built-in template scopes. These expressions previously passed workflow validation but never resolved at runtime, causing the workflows that used these expressions to fail during execution.

Workflow versions are revalidated when they are published, including when an existing unedited version is republished. A workflow containing one of these unsupported expressions now receives an HTTP 409 response during publish. Already-published versions continue to run.

Mitigation: To update affected workflows use ${trigger.*} to read the manual-trigger payload data. To reference output produced by another workflow step, reference that step's ID (for example, ${step_id.result}). Replace any unsupported expressions before publishing the workflow again. For more, see Control workflow execution.

Credentials: deleting a credential used by an integration returns HTTP 409 (2026.8.1788958058)

Copy link

DELETE /credentials/{id} now returns 409 Conflict with the error code CREDENTIAL_IN_USE when the credential is still configured as an integration's management credential. Previously, the request returned HTTP 204 and silently removed the credential, leaving the integration unable to authenticate.

Deleting a credential that is not referenced by an integration continues to return HTTP 204.

Mitigation: Reassign or remove the credential from every integration that references it, then retry the deletion. For more information, see Credential API endpoints.

Workflows: deleting a workflow permanently removes versions and execution history (2026.8.1788958058)

Copy link

Deleting a workflow now permanently removes the workflow, all of its versions, and all executions associated with those versions. These records are removed rather than being marked as deleted, and they cannot be restored through automation orchestrator.

Workflow, workflow-version, and execution API responses no longer include the deleted_at and deleted_by fields. API clients that read or model those fields must be updated. During upgrade, the database migration also permanently removes workflow, workflow-version, and execution records that had already been soft-deleted.

Mitigation: Before deleting a workflow, export any workflow structure that you need to preserve and capture any execution history required for reporting or auditing. A workflow export contains one version's node, trigger, and edge structure. Importing that file creates a new workflow with a new ID and version history; it does not restore the original workflow, its other versions, or its execution records.

Workflows: created_by and updated_by fields become user objects (2026.8.1788958058)

Copy link

Workflow created_by and updated_by fields are now objects ({ "id": "...", "name": "..." }) or null, replacing the previous UUID string format. This applies to workflow list, get, create, update, and publish responses.

Mitigation: Update API clients to read created_by.id and created_by.name instead of treating the field as a bare string. Regenerate any auto-generated API client types.

Resource deletion is now permanent (2026.8.1788958058)

Copy link

Deleting a resource permanently removes it from the database. Previously, automation orchestrator retained deleted resources with a deleted_at timestamp (soft delete). The append-only audit log retains historical records of all delete operations.

This change affects the following resources: users, groups, projects, workflows, workflow versions, executions, tools, tool providers, and identity providers.Deleting a project now cascades to all child resources, including workflows, workflow versions, executions, invocations, credentials, service accounts, approval requests, role assignments, roles, policies, secrets, and file metadata. The project deletion confirmation dialog requires you to type the project name to confirm.

Mitigation: Before upgrading, verify that any resources you might need are exported or backed up. After upgrading, deleted resources cannot be recovered from the database. Use the audit log to review historical records of deleted resources.

API fields created_by and updated_by standardized as user objects (2026.8.1789549281)

Copy link

The created_by and updated_by fields on API responses are now UserReference objects containing id and name properties, or null if the user has been deleted. Previously, these fields returned a bare UUID string on most endpoints and inconsistent formats on others (for example, CredentialWorkflowRef used an ambiguous string-or-UUID union).

This change affects the following API resources: workflows, executions, integrations, tools, groups, service accounts, identity providers, and credentials.

Before:

"created_by": "9f2c...b41a"

After:

"created_by": { "id": "9f2c...b41a", "name": "alice" }

If the referenced user has been deleted or cannot be resolved, the field returns null instead of a raw UUID.

Mitigation: Update API client code that parses created_by or updated_by as strings to handle objects ({"id": "<uuid>", "name": "<username>"} or null). Regenerate any auto-generated API clients from the updated OpenAPI specification.

Workflow definition size and complexity limits enforced (2026.8.1789549281)

Copy link

The API now enforces maximum size and complexity limits on workflow definitions. Previously, the API accepted arbitrarily large workflow definitions, which could cause storage amplification and request-pipeline timeouts.

• Workflow definition request bodies that exceed the maximum size limit are rejected with HTTP 413.
• Workflow definitions with more than the maximum allowed number of nodes are rejected with HTTP 422.

Mitigation: Review existing workflow definitions before upgrading. Workflows that exceed the new limits must be simplified or split before they can be saved. Contact Red Hat support if you have workflows close to these limits and need guidance on restructuring them.

API request body and field size limits enforced (2026.8.1789549281)

Copy link

The API now enforces maximum size limits on request bodies and structured data fields. Previously, the API accepted arbitrarily large payloads, which could cause storage amplification and request-pipeline timeouts.

• JSON and text POST, PUT, and PATCH request bodies that exceed 10 MB are rejected with HTTP 413. The limit is configurable through the APP_API_MAX_REQUEST_BODY_MB environment variable (range 1-120 MB). Clients can alternatively reduce or split payloads.
• Multipart file upload requests are limited based on the configured maximum file count and size (APP_FILE_UPLOAD_MAX_SIZE_MB and APP_FILE_UPLOAD_MAX_FILES). Requests that exceed the effective limit are rejected with HTTP 413.
• Resource labels are limited to 100 entries, with keys up to 253 characters and values up to 256 characters. Labels that exceed 64 KiB serialized are rejected with HTTP 422.
• The context_data, input_data, pre_resolved_nodes, and trigger_inputs fields are limited to 1 MiB serialized JSON.

Mitigation: Review existing resources that use labels or large payloads. Resources with labels or field values that exceed the new limits will fail on their next update with HTTP 422. Audit and normalize any oversized labels before upgrading. No automatic migration is included. Verify that APP_FILE_UPLOAD_MAX_SIZE_MB (range 1-500) and APP_FILE_UPLOAD_MAX_FILES (range 1-100) are within the supported ranges before deploying, because values outside these bounds cause a startup failure.

Service account credential expiration is now enforced (2026.8.1789549281)

Copy link

Service account credentials with an expires_at timestamp are now rejected with HTTP 401 after the expiration time passes. Previously, the expires_at field was stored but not enforced during the authentication flow, allowing expired credentials to authenticate indefinitely. An audit event is now logged when an expired credential is rejected.

Mitigation: Review active service account credentials for expired expires_at timestamps. Rotate any credentials that have passed their expiration date. Credentials without an expires_at value are not affected.

Invocations API removed from the public OpenAPI schema (2026.8.1789549281)

Copy link

The 6 invocation endpoints (create, create_chat, list, get, get_trace, cancel) are no longer included in the public OpenAPI specification or generated API clients. These endpoints were internal plumbing used only by the workflow engine and had no external consumers. The endpoints continue to function internally.

Mitigation: If you generated API clients from the automation orchestrator OpenAPI specification, regenerate them. Remove any references to InvocationsAPI or invocation endpoint types from your code. If your automation depends on invocation endpoints, contact Red Hat support to discuss alternatives using the Executions API.

API naming and path conventions standardized (2026.8.1789549281)

Copy link

Several API schema names, operation IDs, and path segments have been renamed to follow consistent naming conventions:

• IntegrationPatch and IdentityProviderPatch schemas are renamed to IntegrationUpdate and IdentityProviderUpdate.
• SACredential* schemas are renamed to ServiceAccountCredential* (7 schemas).
• IdentityProviderResponse is renamed to IdentityProviderRead.
• The patch_identity_provider operation ID is renamed to update_identity_provider.
• The /auth/ws-ticket path is changed to /auth/ws_ticket.
• The /users_directory and /groups_directory paths are moved to /users/directory and /groups/directory.

Mitigation: Regenerate any auto-generated API clients from the updated OpenAPI specification. Update any hardcoded references to the renamed schemas, operation IDs, or paths listed above.