From 6cf3ffa48f39da68f89bad6f9f3ded0701a5714a Mon Sep 17 00:00:00 2001 From: Oscar Blanco Date: Sun, 10 May 2026 12:43:04 +0200 Subject: [PATCH] fix(runners): wire job_retry.lambda_memory_size and lambda_timeout MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The job_retry variable on both the multi-runner and runners modules declares lambda_memory_size and lambda_timeout, but the local.job_retry map in modules/runners/job-retry.tf never copied either field into the config passed to the inner job-retry / lambda sub-modules. The inner lambda module fell back to its defaults (memory_size = 256, timeout = 60), so user-supplied values were silently dropped. Mirrors the pattern already used by ssm-housekeeper.tf (local.ssm_housekeeper.lambda_memory_size / local.ssm_housekeeper.lambda_timeout) — the ssm-housekeeper Lambda correctly threads the values through; the job-retry one didn't. Observed in production: a deployment pinned to lambda_memory_size = 512 in multi_runner_config[*].runner_config.job_retry produced no plan diff because the value never reached the resource. The job-retry Lambdas were OOM-adjacent at 87% memory utilisation (223 MB peak on the 256 MB default) on a fleet of three runners. --- modules/runners/job-retry.tf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/modules/runners/job-retry.tf b/modules/runners/job-retry.tf index bcaec64625..00ed54d8e1 100644 --- a/modules/runners/job-retry.tf +++ b/modules/runners/job-retry.tf @@ -30,6 +30,8 @@ locals { ghes_url = var.ghes_url lambda_event_source_mapping_batch_size = var.lambda_event_source_mapping_batch_size lambda_event_source_mapping_maximum_batching_window_in_seconds = var.lambda_event_source_mapping_maximum_batching_window_in_seconds + memory_size = var.job_retry.lambda_memory_size + timeout = var.job_retry.lambda_timeout } }