Release notes 0.1.159
27 October 2026: Fixes from the live runs of 0.1.156 to 0.1.158 on 26 and 27 October: a Lambda runtime upgrade is verified by reading the function back, at no cost and without waiting for the…
Release notes · Updated 2026-10-28 · Describes release 0.1.164
0.1.159 — 27 October 2026
Fixes from the live runs of 0.1.156 to 0.1.158 on 26 and 27 October: a Lambda runtime upgrade is verified by reading the function back, at no cost and without waiting for the scanner's clear; a runbook that no longer backs a change is described in one vocabulary on every screen; a stored call's placeholders read as the values its run filled in; and a runbook captured from a published document says where it came from. No new route, setting, permission, audit action, schema change or chart value; one new field, change_class_cause, on a change's meta and on an incident's proposed change. Nothing to do for the upgrade itself (see the upgrade row).
- A Lambda runtime upgrade is verified by reading the function back. A live runtime-upgrade change read not read: no compiled check for a Lambda function in every validation round, its derived CloudWatch window read no datapoints on a function nobody invokes, and the verdict waited 20 to 40 minutes for the scanner's clear after a paid agent run. The steps
aws.lambda.update_runtimeandaws.lambda.update_aliasare now typed checks, like a security-group rule or IMDSv2: the compiled reads already on the change are judged against what the plan intended —GetFunctionConfigurationmust show the runtime the step sent withLastUpdateStatusSuccessful andStateActive or Inactive (an idle VPC function is upgraded all the same), andGetAliasthe version the run published; the runtime or version read before the change means the fix did not hold, and anything else (an update still in progress, a version the run never recorded) is left to the agent. The validation plan's rows and the post-fix recheck's typed rung land the same answer at $0, with no agent run. The derived metric window stays: the function's error rate for 15 minutes after the alias moves fails the fix on a spike, a window with no datapoints decides nothing, and the reads decide once it closes. A Lambda.2 alert that names the function by name scopes the check to the step's function only in the ARN's own account and region when the alert labels them (a function name is unique per account and region). A Lambda step's function is an executed target: a released or verified fix stamps that function's finding only — before, with two open findings of the control (one deferred by a person) nothing was stamped and the scanner's next re-send reopened the incident. - One vocabulary for a runbook that no longer backs a change. A change's Timeline read Standard class dropped — runbook withdrawn for a runbook that had been demoted, and the runbook catalog read Demoted after a rollback for a demotion because a fix did not hold. The cause now lands as a code on the change (
meta.change_class_cause), in thechange.class_droppedaudit payload (cause) and on the incident's proposed change: certification withdrawn by a person; demoted after a rollback, a failed validation or a fix that did not hold; disabled; deleted; no longer certified; changed since the request was drafted. The Timeline heading, the Class block, the runbook catalog and the route row read the same words (Standard class dropped — runbook demoted after a fix that did not hold, Demoted after a failed validation <date>); a row from before carries no cause and reads runbook no longer backs it; a demotion reason the screen does not know reads as its own words, never as a rollback; and the incident page's heading for a request its runbook no longer backs reads Runbook no longer backs it — run it by hand (a deleted or disabled runbook was not withdrawn). - A stored call's placeholders read as the values its run filled in. The page of a Lambda runtime-upgrade change printed
${aiops_lambda_version}and${aiops_alias_revision}inside the alias step's request body and${change_id}inside the backup's: the slots the run fills at execution, shown raw. A reviewed step now reads them from what the run recorded (the step receipt: the version it published, the version the alias pointed at before) and from the change it belongs to (CHG-…); a step that has not run yet, or a receipt written by an earlier release, reads them in plain words, and an unknown slot still reads as words — never a raw placeholder. The change page's preview passes the change id, so the backup slot reads CHG-… instead of a placeholder there too. - Where a published runbook came from. The five AWS-published runbooks carry their source (publisher, document, project and version in
params.source), but only the API and theroute.asr_seededaudit row showed it: the catalog and the route row read like hand-written runbooks. Both now print Published by AWS · <document> · Automated Security Response on AWS v4.1.0 under the runbook's name, and the catalog search finds a runbook by its document name; a hand-written runbook prints nothing. - Documentation. The Lambda runtime runbook chapter and the changes reference say what the live run showed: while a change is verifying, its incident stays remediating; the scanner's clear of the finding does not resolve the incident by itself — the change's verdict decides, the change completes, then the incident resolves.