That's insufficient information on all fronts: what code? what input? what output? what conditions are successful? what conditions are unsuccessful? what are the errors?

I think there is. Its a strategy question (what do when remote process wins and local logging fails), not a code question, it doesn't require code

Your interpretation of the question clearly differs from mine. That's fine.

If the question boils down to: "How do I use SomeApp under certain conditions?", then SomeAppMonks (or equivalent) would be a more appropriate place to post the question than PerlMonks.

On the other hand, if the question boils down to "How do I use Perl to interface with SomeApp under certain conditions?", then PerlMonks would be appropriate and the information provided remains insufficient.

Let's wait for the OP to clarify this.

-- Ken

I think the problem is still not necessarily related to a specific application.

The problem of a half-committed transaction is common, and happens in various locations.

My approach would be to lok at how databases usually do their two-phase commit.

As I haven't really looked deeply into that, I would write a transaction log before sending the transaction to the remote end, and then either record the success or failure of that transaction, or barring any conclusion of the transaction, diagnose an internal error.

This does not provide a magic solution, but it provides a way to determine which transactions need to be manually confirmed.