api: Move close function in condition body

[mi4r]

The close is moved in the body of the error condition.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Does this PR introduce a user-facing change?

   None

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: mi4r
Once this PR has been reviewed and has the lgtm label, please assign mheon for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[baude]

approved not having tests

[baude]

in looking at this PR, I saw the the error is not handled or logged. Then looking at just this file more broadly, sometimes it is and sometimes not. Some are deferred. If we have a consensus on how these should handled in the whole file, I would prefer that. I did not look close enough to verify that this is a possibility.

@mheon @Luap99 wdyt

[Luap99]

I suggested this but it only makes sense if the error on tmpfile.Close() above source = tmpfile.Name() is checked and so that there was no errors during write.

Using defer in this context is not helpful because we want the tmpfile to be closed before we pass the file path to the import API.

[mheon]

I don't think there's value in logging the error from close. Maybe do an explicit _ = xyz.Close() so it's clear we are actually ignoring it.

[Luap99]

I don't think there's value in logging the error from close. Maybe do an explicit _ = xyz.Close() so it's clear we are actually ignoring it.

Read the close() man page, there absolute is a reason to check for errors (even when super unlikely)

A careful programmer will check the return value of close(), since it is quite possible that errors on a previous write(2) operation are reported only on the final close() that releases the open file description. Failing to
check the return value when closing a file may lead to silent loss of data. This can especially be observed with NFS and with disk quota.

I know we ignore this pretty much elsewhere but here we are actually writing something potential large that my increase the odds of hitting such cases.