backport(0.34.x): the KEDA scaling suite (#7620 #7899 #8008 #8424 #6908 #7709) for pinned jacBuilder deploys

[kugesan1105]

Why

jacBuilder runs the pinned 0.34.x release line, and its KEDA scale-to-zero work (jacBuilder#1514, the #8695 wake-latency measurements) needs the declarative KEDA configuration that only exists on main. This PR brings the complete KEDA scaling suite to release/jaclang-0.34.18 so a pinned deploy can drive HTTP scale-to-zero, per-service scale-rate policy, and TriggerAuthentication reconciliation straight from jac.toml.

What is backported (in main's merge order)

PR	Commit on main	What it adds
#7620	5234c81	KEDA HTTP Add-on capability discovery and preflight diagnostics
#7899	91c7adc	per-service hpa.behavior overlay for HPA/KEDA scale-rate policy
#8008	9d2cace	render autoscaler manifests into --show-yaml (prerequisite: #8424 extends exactly this rendering path, it cannot apply without it)
#8424	b908596	render KEDA TriggerAuthentication manifests into --show-yaml
#6908	e092aaa	reconcile KEDA TriggerAuthentications by ownership label (part 2 of #6535)
#7709	6ded655	declarative KEDA HTTP Add-on activation via jac.toml, one mutually-exclusive scaling decision per service

All six are cherry-pick -x, so each commit names its main-side original. #7709's test restructuring is mirrored faithfully: test_keda_autoscaler.jac, test_keda_http_activation.jac and keda_http_activation_verify.jac are deleted here exactly as on main, superseded by test_http_activation_config.jac, test_http_activation_microservices.jac and the shared http_activation_test_support.jac.

Conflict resolutions, and what deliberately did NOT come along

The 0.34.x line diverged from main at 0.34.6 (July 25), so every conflict was resolved by applying only the named PR's own delta and rejecting unrelated main drift:

• plugin_config.jac / runtime/docs.md: only the hpa.behavior and http_activation schema additions were grafted onto the 0.34 text; main's unrelated schema drift (nested_each service schemas, file subkey, changed cpu_target default) was not taken.
• manifest_builder.jac: the ScalingMode enum, _resolve_scaling, the scaling-map bundle shape, and _build_pdb_manifest's HTTP_ACTIVATION early return came in; main's replica-floor/pdb-budget machinery (_replica_floor, pdb_spec, min_available) is separate main work and was not taken, so test_pdb_budget.jac (which tests that machinery) is also not ported.
• target.jac: fix(scale): render autoscaler manifests into --show-yaml, so the reviewed YAML matches what a deploy applies #8008's _autoscaler_spec/render_autoscaler_manifests extraction and feat(jac-scale): support KEDA HTTP Add-on activation via declarative jac.toml config #7709's scaling-map apply loop were taken; the extracted _resolve_service_triggers keeps 0.34 semantics (its has_memory_request read defaults to true, which reproduces this branch's existing behavior exactly).
• kubernetes_target.jac: feat(jac-scale): support KEDA HTTP Add-on activation via declarative jac.toml config #7709's deletion of the legacy imperative destroy/wait path applied cleanly once resolved; no orphaned references remain. One deliberate exception to the no-main-drift rule rode along here: KubernetesTargetBase also loses the whole legacy destroy family (destroy, _destroy_application, _destroy_component, _destroy_database, _destroy_databases, _destroy_cache, _destroy_dashboard, _wait_for_deletion, ~470 lines) that main removed separately. It is dead code on this line too: KubernetesTarget.destroy in target.jac overrides the base and references none of the removed helpers, so nothing could reach them before or after.
• test_pdb_budget.jac itself is not ported (it tests main's replica-floor machinery), but the machinery-free half of its coverage, the _build_pdb_manifest HTTP_ACTIVATION early return and the plan validator's HTTP_ACTIVATION skip, is rehomed as two tests in test_http_activation_microservices.jac (now 32 passing).
• test_plan.jac: the new HTTP-activation render test was adapted to this branch's _run_plan(ms_cfg_pair=...) fixture (main's ms_toml parameter is later drift). One assert in test_memory_trigger_guard.jac uses str(...) around a MagicMock because this line's checker is stricter than main's; it landed one commit later than intended (in the fix(scale): render autoscaler manifests into --show-yaml, so the reviewed YAML matches what a deploy applies #8008 pick) during resolution.
• .github/workflows/ci.yml: feat(jac-scale): support KEDA HTTP Add-on activation via declarative jac.toml config #7709's test-scale-k8s e2e lane was NOT ported. It depends on main-only CI infrastructure (jac-kit action, build-kit job, blacksmith runners) that this branch's CI does not have. The real-cluster e2e script itself (keda_http_activation_real_e2e.sh) ships and can be run manually.
• Release-note fragments are dropped in a final commit, matching this branch's convention (the 0.34.x line writes its notes at publish time, not from release_notes/unreleased/).

Validation

Everything below ran with the published jac 0.34.18 linux-x86_64 release binary against this branch's source:

• jac/jaclang/scale/tests/deploy/: 212 passed, 4 skipped after the final pick (232 passed, 4 skipped including test_plan.jac after the fmt pass).
• The new suites specifically: test_http_activation_config 12 passed, test_http_activation_microservices 30 passed, plus test_show_yaml_autoscalers, test_memory_trigger_guard, test_factories, test_deployment_overlay, test_plan all green.
• jac/jaclang/scale/tests/microservices/: 217 passed; the 12 failures in test_drain, test_fleet_pod_optout and test_rate_limit fail identically on the untouched branch head (verified side by side at 529fb29), so they are pre-existing on this line and unrelated to the backport.
• jac fmt with the 0.34.18 binary over every touched file, committed separately per this branch's convention.

[MusabMahmoodh]

Read the six cherry-picks against their main originals rather than as one diff. The backport discipline is good: -x on every pick so each names its original, the exclusions are stated with reasons instead of being silent, and #7709's test restructuring is mirrored rather than half-applied. #8008 is mine, and test_show_yaml_autoscalers.jac came across intact, so the --show-yaml rendering keeps its coverage on this line. That was the thing I would have checked first.

Three things, and the first is the one I would hold the merge on.

1. Nothing tested this.

ci.yml triggers on pull_request: branches: [main] and push: branches: [main]. This PR targets release/jaclang-0.34.18, so none of it ran. The two checks on the PR are pre-commit.ci (green) and [code]smith (skipped). So 34 files and roughly 3,500 lines of scale changes are going onto the branch jacBuilder pins its deploys to, and the only thing that has looked at them is a formatter.

That is a different risk profile from the same code on main, because on main the next PR pays for a mistake and here a fleet does. The 2026-08-06 template regression is the shape I have in mind: config-level change, correct-looking diff, found in production.

What I would want before this merges is one of: a workflow_dispatch run of CI against this ref (the trigger is already there, it just needs pointing at the branch), or the scale suites run on a rig against a binary built from this head with the result pasted here. Either is cheap next to re-deriving it after a pinned deploy misbehaves.

2. The largest change in the diff is a 470-line deletion that the body does not mention.

8eb3b11b2 (the #7709 pick) takes KubernetesTargetBase from 1,318 to 848 lines, removing destroy, _destroy_application, _destroy_component, _destroy_database, _destroy_databases, _destroy_cache, _destroy_dashboard and _wait_for_deletion. kubernetes_target.jac still exists on main at full size, so this is not something #7709 did upstream.

I chased it and it is fine: KubernetesTarget.destroy in target.jac overrides the base and references none of the seven removed helpers, so the removed family was already unreachable on this branch and nothing calls into it. Good removal, in other words. But the body says every conflict was resolved by applying only the named PR's own delta and rejecting unrelated main drift, and this is unrelated main drift that was taken. On a release branch that is the sentence a release reviewer most needs, and right now they have to derive it the way I just did. One line in "what deliberately did NOT come along" saying the dead destroy family went too, and why it is dead, would close it.

3. A PDB behavior change ships here with its test left behind.

_build_pdb_manifest's HTTP_ACTIVATION early return came across, and test_pdb_budget.jac did not, because the replica-floor machinery it also covers is separate main work. That reasoning is right for the machinery and wrong for the early return: the branch now changes what a PDB looks like for an HTTP_ACTIVATION service with nothing asserting it, on a branch where point 1 means nothing asserts anything. If the budget half of that file is what does not port, the early-return half is small enough to bring over on its own.

[MusabMahmoodh]

Filed the general case as #8947, since it is not yours to fix in a backport PR: no workflow in the repo triggers on a release/* branch or a PR targeting one, so this is the third backport in a row (with #8038 and #8701) to arrive with only pre-commit.ci having looked at it.

Point 1 of my review still stands for this PR specifically. A workflow_dispatch run of CI against this ref would settle it today without waiting on #8947.

[kugesan1105]

@MusabMahmoodh all three addressed, in your order.

1. Test evidence, pasted, plus stronger system-level evidence than a CI dispatch would give.

A workflow_dispatch of upstream CI cannot point at this ref (the head lives on a fork, and dispatch refs must exist in this repo), so here is your second option, the suites run against this exact head (5de53909d) with the published jac 0.34.18 linux-x86_64 release binary:

• jac/jaclang/scale/tests/deploy/: 223 passed, 4 skipped (the 4 are the k8s-gated e2e, no cluster on the rig).
• jac/jaclang/scale/tests/microservices/: 273 passed, 45 failed, and all 45 are environment-limited, not backport regressions: 40 in test_gateway.jac and 5 in test_app_routes.jac, every one failing on scale/admin/ui/main.jac failed to compile (the admin-UI client build needs the client toolchain the rig lacks). Verified by running both files on the untouched branch point 529fb296e in the same environment: identical failures, identical counts (40 and 5). Same story as the pre-existing test_drain/test_fleet_pod_optout/test_rate_limit dozen already noted in the body.

Beyond the suites, this head has also been under a real fleet: jaseci/jaclang:experimental-8948 is this branch plus one test-only fleet-gate commit, and it was deployed twice to EKS via jacBuilder#1642 (runs 33841609863 and 34166918740, four days apart), full fleet rollout, KEDA ScaledObjects applied by the backported path, scale-to-zero wake measured both times (cold/warm 94/96s and 94/92s). The pinned-fleet risk you describe is exactly what those runs exercised.

2. The 470-line deletion is now in the body.

Added to "what deliberately did NOT come along", stating the whole legacy destroy family that left with the #7709 pick, that it is unrelated main drift which was taken, and why it is safe: KubernetesTarget.destroy in target.jac overrides the base and references none of the removed helpers, so the family was unreachable on this line before and after. You should not have had to derive that; thank you for chasing it.

3. The machinery-free half of the PDB coverage is ported.

5de53909d rehomes the two tests into test_http_activation_microservices.jac using its existing fixtures: an HTTP-activated service gets no PDB even with pdb.min_available set (through the real generate_manifests path) and the plan validator skips the HPA and PDB checks for an HTTP_ACTIVATION service. Suite is 32 passing with them. test_pdb_budget.jac itself still stays behind, since the rest of it tests the replica-floor machinery this line does not carry.

[MusabMahmoodh]

Re-reviewed the new commit (5de5390). Rehoming the two machinery-free tests into test_http_activation_microservices.jac and reusing its existing fixtures is the right call over carrying test_pdb_budget.jac and the replica-floor machinery this line does not have. Both tests drive a real ManifestBuilder over a real temp project rather than stubbing the bundle, which is what I would have asked for.

Two things.

The PDB assertion passes for the wrong reason too. assert bundle.get("pdbs", {}).get("billing_ops") is None; holds when the PDB is correctly suppressed, and equally when pdbs is absent, when the service key never made it into the bundle, or when generate_manifests returned early for an unrelated reason. It cannot tell "suppressed because HTTP_ACTIVATION" from "PDB generation did not run".

A second service in the same services dict, same pdb.min_available = 1, without http_activation, fixes it: assert that one is in bundle["pdbs"] and billing_ops is not. Same builder call, one more dict entry, and then the test can only pass for the reason it claims.

The validator test asserts on message prose. "HPA" in m and "PodDisruptionBudget" in m or "pdb." in m go quiet the day someone rewords the diagnostic, and quiet in the direction of passing. Does the diagnostic object carry a code or a rule identifier alongside .service and .message? If it does, asserting on that is the version that survives a rewording.

Point 1 from my last review still stands, and is sharper now. The only check on this head is [code]smith, skipped. A test-only commit landed on a backport branch and nothing executed it. #8947 covers the general case, but for this PR a workflow_dispatch run of CI against the ref would settle it today rather than merging four test commits nothing has run.