[BUG] [cpp-ue4] generated code doesn't properly check for connection failures

Bug Report Checklist

• Have you provided a full/minimal spec to reproduce the issue?
• Have you validated the input using an OpenAPI validator (example)?
• Have you tested with the latest master to confirm the issue still exists?
• Have you searched for related issues/PRs?
• What's the actual output vs expected output?
• [Optional] Sponsorship to speed up the bug fix or feature request (example)

Description

The generated code for handling REST requests and responses doesn't properly check for connection failures. Also, when it defaults into a connection failure scenario later on, it erroneously injects a HTTP response code of 408. Unreal's own files say that response means:

		// the server timed out waiting for the request.
		RequestTimeout = 408,

this can be seen at the end of the "HandleResponse" method in the Api object. Quoting the template:

	// By default, assume we failed to establish connection
	InOutResponse.SetHttpResponseCode(EHttpResponseCodes::RequestTimeout);

This code is reached when the HTTPRespone is null, or bSuccess is false. In the case of a connection failure, the server never responded but we got here anyway; and now, the REST protocol layer is pretending that the server sent a response and a code that it never sent. This behavior is very problematic.

For my part, I was trying to catch the 408 response by debugging my server code because of course, an http response code that is reserved for an actual server to send, is being sent by the server right? Nope. Eventually I debugged Django deeply enough to suspect that the connection was being rejected and thought to check for client side code making up the 408 error out of thin air. Perhaps it was Apple's WebKit client? Nope, it was the generated REST code from the template.

What likely should be happening is: before constructing a response, the client should probably check the request for its status.

from the existing template:

void {{classname}}::On{{operationIdCamelCase}}Response(FHttpRequestPtr HttpRequest, FHttpResponsePtr HttpResponse, bool bSucceeded, F{{operationIdCamelCase}}Delegate Delegate) const
{
	{{operationIdCamelCase}}Response Response;
	HandleResponse(HttpResponse, bSucceeded, Response);
	Delegate.ExecuteIfBound(Response);
}

The HttpRequest has a GetStatus() method which could be leveraged as such before actually trying to "HandleResponse" when a response actually never happened:

void OrgbuilderApi::OnUpdateLegalEntityResponse(FHttpRequestPtr HttpRequest, FHttpResponsePtr HttpResponse, bool bSucceeded, FUpdateLegalEntityDelegate Delegate) const
{
	//handling a response that isn't an actual response would be a problem.
	switch (HttpRequest->GetStatus())
	{
	case EHttpRequestStatus::Failed :
		{
			UpdateLegalEntityResponse Response;
			Response.SetHttpResponseCode(EHttpResponseCodes::Unknown);
			Response.SetResponseString("Client reports request connection failed: " + HttpRequest->GetURL());
			Response.SetSuccessful(false);
			Delegate.ExecuteIfBound(Response);
		}; break ;
	case EHttpRequestStatus::Failed_ConnectionError :
		{
			UpdateLegalEntityResponse Response;
			Response.SetHttpResponseCode(EHttpResponseCodes::Unknown);
			Response.SetResponseString("Client reports request connection failed but could be retried: " + HttpRequest->GetURL());
			Response.SetSuccessful(false);
			Delegate.ExecuteIfBound(Response);
		}; break ;
	default :
		{
			//we likely have an actual response to handle.
			UpdateLegalEntityResponse Response;
			HandleResponse(HttpResponse, bSucceeded, Response);
			Delegate.ExecuteIfBound(Response);
		};
	}
}

I'm not thrilled with this solution. Because we're still technically telling the downstream developer that a response happened. Though I'm much happier at least setting the response to Unknown (0) and passing along a response string that describes this as a client talking about a client connection error.

// status code not set yet
		Unknown = 0,

lastly, we'd likely change the fall through in HandleResponse to something like this, to keep the general structure in place:

	// By default, assume we failed to establish connection
	InOutResponse.SetHttpResponseCode(EHttpResponseCodes::Unknown);
	if (bSucceeded)
	{
		InOutResponse.SetResponseString(TEXT("The client didn't report a connection failure, but it received no response."));
	} else
	{
		InOutResponse.SetResponseString(TEXT("The client didn't report a connection failure, but the request was not succesful."));
	}

But really we probably need a more descriptive interface here where a downstream developer can be informed of client connection failures, as a separate matter from handling server responses.

openapi-generator version

development HEAD

OpenAPI declaration file content or url

any valid file will generate this code.

Generation Details

any cpp-ue4 generated api will generate this code.

Steps to reproduce

• generate any api with cpp-ue4 to see the code.
• If trying to create this client-server condition, one might try putting up a firewall, which should reject client connection requests.

Related issues/PRs

none

Suggest a fix

see above.

tagging @Kahncode

Start with the cpp-ue4 template containing On{{operationIdCamelCase}}Response and HandleResponse, then generate any API and reproduce a rejected connection as described. Trace HttpRequest status, HttpResponse, and bSucceeded through the callback. Done means connection failures are distinguishable from server responses and are not reported as HTTP 408.