chore(deps): update dependency promptfoo to v0.120.24

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
promptfoo	0.120.23 → 0.120.24

---

Release Notes

promptfoo/promptfoo (promptfoo)

v0.120.24

Compare Source

Features

• add --filter-prompts option with MCP alignment (#​7451) (e9b53e2)
• eval: add hidden column indicators and schema-based column visibility persistence (#​7536) (8fbeb60)
• fetch: add Cloudflare 524 timeout to transient error retry (#​7590) (e7c1c81)
• providers: add Claude Opus 4.6 support across all platforms (#​7506) (850c3bf)
• providers: add pricing support for Google AI Studio models (#​7491) (ffcacd4)
• providers: disable MCP caching by default, add cache_mcp opt-in (#​7518) (3f224a6)
• real estate plugins (#​7494) (ef92072)

Bug Fixes

• deps: update dependency @​modelcontextprotocol/sdk to ^1.26.0 (#​7588) (3902784)
• deps: update dependency @​octokit/auth-app to ^8.2.0 (#​7560) (b7d9b4d)
• deps: update dependency @​opencode-ai/sdk to ^1.1.49 (#​7559) (08ebaae)
• deps: update dependency @​opencode-ai/sdk to ^1.1.50 (#​7578) (3697c4f)
• deps: update dependency @​opencode-ai/sdk to ^1.1.51 (#​7580) (22630d1)
• deps: update dependency glob to ^13.0.1 (#​7568) (d783cdc)
• deps: update dependency minimatch to ^10.1.2 (#​7570) (12d604c)
• deps: update dependency ora to ^9.2.0 (#​7581) (8f4fc1e)
• deps: update dependency posthog-node to ~5.24.10 (#​7584) (d47b996)
• deps: update dependency posthog-node to ~5.24.9 (#​7564) (644bc11)
• deps: update dependency semver to ^7.7.4 (#​7602) (6882a4d)
• deps: update openai packages (#​7577) (cc71973)
• eval: correct promptIdx alignment with test-level filtering (#​7544) (0f4ae84)
• eval: fix SSL "bad record mac" errors under concurrent API load (#​7466) (5eb903b)
• eval: show more toggle for metrics in cells for evals (#​7530) (1367921)
• huggingface: concurrent dataset fetching (#​7423) (eefc8be)
• improve clarity of which model is being used in logging redteams (#​7508) (2e2a7cb)
• providers: add missing Claude Opus 4.6 entries for Bedrock, Vertex, and OpenRouter (#​7543) (e20ae6a)
• redteam: deduplicate global grader examples (ENG-1780) (#​7593) (dddfc18)
• redteam: preserve provider config when importing YAML in setup UI (#​7457) (18f848b)
• stop plugin filters jumping in redteam setup (#​7557) (05685c0)

---

Configuration

📅 Schedule: Branch creation - "before 10am on friday" in timezone Europe/London, Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[github-actions]

Open in Overmind ↗

---

model|risks_v6
✨Encryption Key State Risk ✨KMS Key Creation

🔴 Change Signals

Routine 🔴 ▇▅▃▂▁ AWS instance resources showing infrequent updates with only 1 event/week for the last 6 weeks, which is unusual compared to typical patterns.
Policies 🔴 ▃▂▁ S3 bucket 'aws_s3_bucket.terraform-example-state-bucket' is missing required tags and server-side encryption, and security group allows SSH access from anywhere, which is unusual compared to typical patterns.

View signals ↗

---

🔥 Risks

Tip

✔ All risks disproven

We investigated 2 potential risks across 28 resources and verified each was safe. See the investigation details below.

---

🧠 Reasoning · ✖ 2 · ✔ 0

EIP association or re-mapping may break public reachability and DNS routing

Observations 1

Hypothesis

Changes to the association of Elastic IP 13.134.236.98 (allocation ID eipalloc-05a1609afb54e84ed, association ID eipassoc-00e132946511a178e) may disrupt network reachability for resources that depend on this public IP. If the EIP is re-associated or a different allocation/association is used, DNS records pointing to this EIP may effectively route to a different underlying resource or become invalid until updated, causing connectivity interruptions.

Investigation

I examined the plan and current state. The Elastic IP 13.134.236.98 is currently allocated as eipalloc-05a1609afb54e84ed and associated (eipassoc-00e132946511a178e) to ENI eni-020b762e197effb8a on instance i-06454595ec548264a with private IP 10.0.101.48. The DNS record ec2-13-134-236-98.eu-west-2.compute.amazonaws.com resolves directly to 13.134.236.98 with a short TTL. In the planned changes, the EC2 instance will be replaced (AMI change), but the ec2-address resource shows an "updated" change with no diff details; there is no evidence of a new allocation, a different public IP, or a permanent switch to a different EIP. When an instance is replaced, an EIP can be re-associated to the new primary ENI without any DNS change because DNS points to the static EIP, not to the instance/ENI. Therefore, the hypothesized risk that DNS will become invalid or point to the wrong public IP is not supported by the evidence. At most, there could be a brief reachability blip during instance replacement/re-association, but that is not the claimed DNS routing break and there is no indication of a new EIP allocation or lingering disassociation.

✖ Hypothesis disproven

---

EC2 instance replacement risks: EBS attachment integrity and ALB IP-registered target health

Observations 8

Hypothesis

Replacing EC2 instance i-06454595ec548264a (e.g., due to AMI or hibernation configuration changes) will trigger detach/reattach of EBS volume vol-0e2b4296b2bd81424 and may change or unassign its primary private IP 10.0.101.48. The ALB target group api-health-terraform-example registers targets by IP (10.0.101.48) on port 9090/TCP; if the replacement instance does not retain this IP or it is temporarily unassigned, the target group will contain stale/invalid IP targets, causing failed health checks and traffic disruption until targets are updated or re-registered. Improper EBS detach/reattach sequencing during this replacement can also cause brief storage unavailability or data consistency issues if writes are in flight without clean shutdown, snapshots, or backups.

Investigation

What’s actually changing: the EC2 instance i-06454595ec548264a is being replaced (AMI change) and the aws_lb_target_group_attachment for api-health-terraform-example is also planned to be replaced; the Elastic IP resource is updated. Current state shows the NLB target group api-health-terraform-example is target_type=ip on port 9090/TCP, with a single healthy target 10.0.101.48. The instance’s primary ENI has private IP 10.0.101.48, and its root EBS volume /dev/xvda has DeleteOnTermination=true.

Evaluation of the two claims:

1. Stale IP target risk: By design, NLB target groups of type ip register targets by IP, not instance ID. If the instance is terminated and relaunched, its primary private IP is released and a new instance normally gets a different private IP unless explicitly set. However, this change plan already includes replacement of the aws_lb_target_group_attachment, which is the mechanism Terraform uses to (re)register the correct target IP with the target group. With that attachment being recreated during apply, the target should be updated to the new private IP as the new instance comes up. There is no evidence in the diffs that would force a destroy-then-create ordering that guarantees downtime, nor any indication that the attachment will be left stale. Therefore, while a very brief window is possible in a single-target setup, the hypothesis asserts a definite disruption without supporting evidence; this is speculative rather than a confirmed breaking condition. Documentation: target groups with target_type=ip register by IP; Terraform aws_lb_target_group_attachment registers a specific IP/ID; primary private IPs are released on termination and reassigned on new launches. (docs.aws.amazon.com)
2. EBS detach/reattach integrity risk: The only attached volume is the root volume with DeleteOnTermination=true. On replacement, the root volume is deleted when the old instance is terminated; there is no detach/reattach sequencing of a persistent data volume. This invalidates the claimed risk of data inconsistency from improper detach/reattach for this change. AWS documentation confirms the default DeleteOnTermination behavior for root volumes. (repost.aws)

Additional note: The load balancer here is a Network Load Balancer (listener ARN path contains /net/ and health checks are TCP), not an ALB, but this does not materially change the assessment. Given the planned re-registration and the absence of a persistent EBS data volume, there isn’t strong evidence of a real, breaking risk tied to this change.

✖ Hypothesis disproven

---

💥 Blast Radius

Items 28

Edges 67

[github-actions]

✅ Auto-Approved

---

🟢 Decision

Auto-approved: All safety checks passed

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2)

---

📊 Signals Summary

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2)

---

📊 Signals Summary

Policies 🔴 -3

Routine 🟢 +5

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

View full analysis in Overmind ↗

[github-actions]

⛔ Auto-Blocked

---

🔴 Decision

Auto-blocked: Policy signal (-3) is below threshold (-2); Routine score (-5) is below minimum (-1)

---

📊 Signals Summary

Routine 🔴 -5

Policies 🔴 -3

---

🔥 Risks Summary

High 0 · Medium 0 · Low 0

---

💥 Blast Radius

Items 28 · Edges 67

---

View full analysis in Overmind ↗