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 an undefined 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 an undefined union for updateTemplateMeta?

   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's data argument could also be broadened to include undefined as a bandaid solution

export const updateTemplateMeta = async (
  templateId: string,
  data: TypesGen.UpdateTemplateMeta,
): Promise<TypesGen.Template | undefined> => {
  const response = await axios.patch<TypesGen.Template | undefined>(
    `/api/v2/templates/${templateId}`,
    data,
  );
  return response.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 {
    await queryClient.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 (though null 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 whether data.name is the string literal "undefined"? Even in the bug issue, the previous code wasn't breaking when it was trying to access the name 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 setting name 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:

interface Template {
  readonly name: "undefined" | (string | {}); // (string | NonNullable<unknown>) also works
}

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

The response is a completely empty payload, 0 bytes.

You are saying that is null and not undefined?