fix(planner): propagate DGDSA /scale 404 instead of patching the parent DGD

[brucezhao1875]

Summary

In the pinned Dynamo v1.3.0 source, KubernetesAPI.update_service_replicas catches an ApiException 404 from the DGDSA /scale subresource and calls _update_dgd_replicas. That fallback reads the parent DynamoGraphDeployment and sends a JSON Patch to the DGD main resource (/spec/components/{i}/replicas). A missing DGDSA therefore changes the write surface instead of propagating the scale error.

For Planner-managed scaling, the DGDSA /scale path is the intended control surface. A DGDSA 404 should propagate as an ordinary error; it must not fall back to a direct DGD main-resource write.

Pinned reproduction and evidence

• Pinned source: Dynamo v1.3.0, commit 8ce9e22f11576402102ea9d8b8e46233f5430a0d, tree 617b6abe3049d573ad45258676d1600a7cb56e37.
• Affected path in that tree: components/src/dynamo/planner/connectors/kubernetes_api.py, KubernetesAPI.update_service_replicas (the 404 branch and _update_dgd_replicas helpers).
• Route-C subtraction carrier: patch SHA-256 63cc3d41ae432f9ed9f0d3d5e097e241609594745e433cc803eff607c29697f2, 2 files, +15/-223.
• The recorded controlled-local proof applied the patch cleanly, verified both patched in-image module copies by digest, and passed the focused update_service_replicas / update_graph_replicas selection 3/3.
• The behavioral proof used a fake DGDSA /scale 404: the patched code propagated 404, made exactly one /scale call, and made no DGD GET or PATCH. The contrast harness against the pristine module observed the prior DGD GET plus main-resource JSON Patch fallback.

Expected behavior

1. DGDSA /scale success performs one DGDSA scale patch and no DGD main-resource request.
2. DGDSA /scale 404 propagates unchanged and performs no DGD GET or main-resource JSON Patch.
3. Other DGDSA errors propagate unchanged and do not invoke a fallback.
4. The deprecated update_graph_replicas alias retains the same no-fallback behavior.

Current upstream observation

As of 2026-08-19, the fallback remains in the inspected v1.3.1, v1.4.0, and main source trees. The later trees moved the module to components/src/dynamo/planner/connectors/clients/kubernetes_api.py, so the pinned subtraction patch should be rebased and retested rather than applied blindly.

Related context

The repository history includes PR #4825 (introducing Planner DGDSA scaling with fallback), issue #12080 and PR #12087 (DGDSA/DGD replica-intent ownership), and PR #9450 (enabling DGDSA for Planner-managed DGDR workers). I did not find an existing issue or PR specifically proposing propagation of the DGDSA 404 instead of the direct-DGD fallback.

Scope and carrier retirement

This report is an upstream discussion request, not a request to change the local Nexus carrier in place. Route C remains the accepted local carrier for pinned Dynamo 1.3.0. If upstream accepts an equivalent fix, a separate decision must verify the selected upstream source, rebuild and re-prove the pinned artifact, and then decide whether the Route-C carrier and pin can be retired. No pin bump, carrier deletion, image push, deployment, or release change is requested here.

[ayaangazali]

I looked at picking this up and stopped, because on current main the fallback reads as intended behaviour rather than a defect. Posting the evidence in case it saves someone else the same detour.

The file moved to components/src/dynamo/planner/connectors/clients/kubernetes_api.py, and update_service_replicas still has the 404 branch. Its docstring states the fallback as the contract:

Update replicas for a component using Scale subresource when DGDSA exists.
Falls back to a direct DGD patch when the component does not have a DGDSA.

with the branch itself commented # DGDSA doesn't exist - fall back to a direct DGD patch. There is also existing coverage pinning the fallback path, test_update_dgd_replicas_directly in components/src/dynamo/planner/tests/unit/test_kube.py.

So the disagreement is about whether a DGDSA is required for Planner-managed scaling. The issue takes it as given that /scale is the intended control surface and a 404 should propagate; the code takes the opposite position, that a component without a DGDSA is a supported configuration that scales through the DGD directly. Removing the fallback would stop scaling working for those deployments, which is a behaviour change for a supported path rather than a bug fix, and the +15/-223 shape suggests that is the intent.

That call belongs with maintainers, so I have not opened a PR. Two things would settle it: whether a DGDSA is now guaranteed for every Planner-managed component, and if so whether the fallback should be removed or kept as a deprecated path with a warning.

One note on the report itself, meant helpfully: it is pinned to v1.3.0 at commit 8ce9e22f1, and the paths cited do not exist at those locations on main any more. Anyone verifying it will need the current path above.