Silent behavior on no body responses

[insyri]

Abstract

The httpRaw method (concerned portion shown below) has a defect where it will resolve the function normally if there is no body. This skips type checks since the empty response it is casted to the generic type of the expected structure and thus lies to users. Without knowing the internal functionality of how it resolves this case, users may find unexpected bugs that can skip this check. Of course, this method isn't exactly expected to be adopting use in projects depending on Tpy, however, since the method is made public, it should be able to be used as normally.

tpy/src/tpy.ts

Lines 350 to 354 in 6c9a2ca

	const body = await response.text();
	if (response.ok) {
	// This is bad, I know. You fix it. Please.
	return (body.length === 0 ? {} : JSON.parse(body)) as unknown as T;
	}

This original functionality was created with the KV put operations in mind (see put and putArrayBuffer; notice the methods do not capture the response) since those endpoints return no body. If I remember correctly, the reason behind this design choice was to avoid some type collisions internally, mostly a lazy -or uneducated- solution.

Proposal

I imagine those who are accessing endpoints that return no body expect this behavior, this leads me to believe that the proper approach to this would be to tell the type system to expect this, negating the generic type (if there is one) entirely and returning nothing at all or some nullish value.

Since we would also be changing the logic, this would go beyond the type system and implemented into the method itself. This may entail an extra parameter and maybe a type parameter (or at least a conditional operation) to follow this process of logic.

[insyri]

Something I ran into while creating this parameter: as this kind of parameter would have inserted data in certain situations, it cannot be appended to the end of the list of the parameters of httpRaw. It would be required for the arrangement of the parameters to be changed. This would require a change in all invocations, yes, however, my concern is more that these parameters are becoming more complex making it hard to remember or predict what the next parameter will be. I think it may be beneficial to change additional options (optional parameters) to an entire object following an interface.

This also reminds me of the current constructor parameter setup. Should this be addressed in a later issue.