I know I may be considered a little off the wall here but there is another option.
We know that from time to time there is a bug that happens on transit.We know that there is not much we can do right now to stop the problem. If you are only providing the API then stop reading however if you write the client too, keep going.
The error is a known case, and known cause. The result of an empty return value means that something went wrong. However the value is available and was fetched, calculated, whatever… My instinct as a developer would be to treat an empty result as an HTTP error and request the data be resent. You could then track the resend requests and see how often this happens.
I would suggest (although you strike me as the kind of developer to think of this too) that you count the requests and set a sane value for responding “network error” to the user. My instinct would be to retry right away and then to wait a little while before retrying some more.
From what you describe the first retry would probably pick up the data properly. Of course this could mean keeping older requests hanging about in cache for a few minutes or running the request a second time depending on what seemed most appropriate.
This would also route around any number of other point-to-point networking errors and leave the app far more robust even in the face of connectivity problems.
I know our instinct as developers is to fix the known fault but sometimes it is better to work towards a system that is able to operate despite faults. That said it never hurts to log errors and problems and try to fix them anyway.