Change:
return scale, foundSpecReplicas, nil } <ins> type scaleUpdatedObjectInfo struct { reqObjInfo         rest.UpdatedObjectInfo specReplicasPath   string statusReplicasPath string labelSelectorPath  string } func (i *scaleUpdatedObjectInfo) Preconditions() *metav1.Preconditions { return i.reqObjInfo.Preconditions() } func (i *scaleUpdatedObjectInfo) UpdatedObject(ctx context.Context, oldObj runtime.Object) (runtime.Object, error) { cr := oldObj.DeepCopyObject().(*unstructured.Unstructured) const invalidSpecReplicas = -2147483648 // smallest int32 oldScale, replicasFound, err := scaleFromCustomResource(cr, i.specReplicasPath, i.statusReplicasPath, i.labelSelectorPath) if err != nil { return nil, err } if !replicasFound { oldScale.Spec.Replicas = invalidSpecReplicas // signal that this was not set before } obj, err := i.reqObjInfo.UpdatedObject(ctx, oldScale) if err != nil { return nil, err } if obj == nil { return nil, apierrors.NewBadRequest(fmt.Sprintf("nil update passed to Scale")) } scale, ok := obj.(*autoscalingv1.Scale) if !ok { return nil, apierrors.NewBadRequest(fmt.Sprintf("wrong object passed to Scale update: %v", obj)) } if scale.Spec.Replicas == invalidSpecReplicas { return nil, apierrors.NewBadRequest(fmt.Sprintf("the spec replicas field %q cannot be empty", i.specReplicasPath)) } specReplicasPath := strings.TrimPrefix(i.specReplicasPath, ".") // ignore leading period if err := unstructured.SetNestedField(cr.Object, int64(scale.Spec.Replicas), strings.Split(specReplicasPath, ".")...); err != nil { return nil, err } if len(scale.ResourceVersion) != 0 { // The client provided a resourceVersion precondition. // Set that precondition and return any conflict errors to the client. cr.SetResourceVersion(scale.ResourceVersion) } return cr, nil } </ins>

Discussion:
What happened: Using a command such as: fails with the following error: This bug happens on each run and started occurring as of v1.15.0. With v1.14 or older, I don't have such problem, i.e. it works flawlessly. What you expected to happen: The command succeeds: How to reproduce it (as minimally and precisely as possible): Create a CRD that has the scale subresource and try to scale a CR using . Example of such CRD can be found . Anything else we need to know?: Regarding the bug, it seems that it started appearing as of . Before the PR, we always fetched the resource and it worked because it had the resource version, while now we are only fetching it in case preconditions are provided (preconditions are not provided by default/when using ). Here is the output of a command: If I manually craft the request that has the resource version (or use the flag), it works. Is it as expected that the Scale resource requires the resource version in order for update to succeed? Shouldn't it always pick the latest resource version in case it isn't provided? On that note, I also noticed that if you want to update a CR by crafting the request manually and using , you also need to specify the resource version or you will get the same error. I'm not sure if this is expected and related, but I'm writing it down as it might be related. As far as I know, this is not required for some native resources at all, but I'm not sure is this the case for CRDs. Environment: Kubernetes version (use ):
/sig api-machinery cc
/sub
could you try to see if it fix the problem?
I've created a test cluster based on and I can confirm that I'm able to scale CustomResources using as usual. I used an to test this, such as: Thanks a lot for your time spent fixing this!
Bug triage for 1.17 here with a gentle reminder that code freeze for this release is on November 14. Is this issue still intended for 1.17? I see you move it to 1.17 so I just wanted to be sure.
I guess could be merged now?

It is in the review queue and should still make 1.17
a kind reminder that code freeze for this release is on November 14.
I wanted to circle back around on this. We are 4 days out from code freeze. If this is still good based on just note here. Judging from the looks of it we are still good
Yes this should merge early in the week
Code freeze is tomorrow, this still going to make it?
yes, is still planned