When we noticed the problem with the hub, it was because an attached device was not behaving to spec. The problem with the hub caused a packet to get corrupted. As the packet was corrupted, the packet was not ACKed. The host retried the packet and the device in question responded with a zero length packet. That is an error on the device part, the correct response to a retry is to resend the packet which has not been acked. The device's failure to follow the spec then caused other issues that caused the problem to be noticed (a file copy hung).
USB should be able to cope with corrupted packets on the bus, its when devices don't follow the spec with regards to recovery from the errors that things get "interesting".
So is your device behaving correctly to spec in the face of unexpected errors?
I would note that we've had other devices which would occasionally corrupt a packet, but as error recovery was properly followed, this never resulted in a symptom the user would notice. We only noticed it by looking at bus traces. We've sold millions of such devices and I'm not aware of any user complaints caused by the behaviour.