Probably worth keeping, it was the original report.

I think this change works for our purposes here. I guess there's just two other things that come to mind:

1. At the end of the day, we do need anundefined check, but right now, there's nothing surfacing that the data could be undefined at the type level.

   My worry is that someone will see that we're doing a check for something that appears non-nullable, and not be sure whether the comment still applies. Could you also add anundefined union forupdateTemplateMeta?

   I know that we're using this API call in two other files, though, so there might be some edge cases with changing it everywhere.onSuccess'sdata argument could also be broadened to includeundefined as a bandaid solution

exportconstupdateTemplateMeta=async(templateId:string,data:TypesGen.UpdateTemplateMeta,):Promise<TypesGen.Template|undefined>=>{constresponse=awaitaxios.patch<TypesGen.Template|undefined>(`/api/v2/templates/${templateId}`,data,);returnresponse.data;};

2. I haven't dived too deeply into our settings stuff, but my gut feeling is that we don't necessarily need to invalidate the queries and go through a refetch if no data has changed. I wonder if something like this might be good:

onSuccess:async(data)=>{if(!data){data=template;}else{awaitqueryClient.invalidateQueries(templateByNameKey(orgId,data.name),);}}

This is all good info and I will make these changes. Other places call this, but have to handle the undefined too.

This is the fix.

This is all good info and I will make these changes. Other places call this, but have to handle the undefined too.

Oh wait, I just realized something – I'm worried the logic isn't quite right.undefined isn't a valid JSON-serializable value (thoughnull is), so it shouldn't be able to make it across the API boundary in the first place

Is the condition we should actually be checking for whetherdata.name is the string literal"undefined"? Even in the bug issue, the previous code wasn't breaking when it was trying to access thename property during the navigation – it was just being fed an incorrect value. That's making me think that technically,data and its properties would always be defined – it's just that we're simulating "undefined-ness" by settingname to"undefined" in certain situations

This is definitely out of scope for the PR, and I haven't explored our type generation logic, so I don't know how complicated this would be, but there is a trick we can use to add the literal"undefined" to autocomplete without narrowing the overall type unnecessarily:

interfaceTemplate{readonlyname:"undefined"|(string|{});// (string | NonNullable<unknown>) also works}

With that, "undefined" would show up during autocomplete, but the overall type would still bestring

The response is a completely empty payload, 0 bytes.

You are saying that isnull and notundefined?