from memory, "reset project" after running down the wu's was how I got past this.

The communication is always two step, really 4 steps in a 2 cycle process.

1a) Client > Server: Send file(s) to file server
1b) Server > Client: Confirm receipt from fileserver (one for each file of a result).
2a) Client > Server: OK, got the file receipt(s) confirmation(s), now sent the Ready to Report to scheduler.
2b) Server > Client: Send ack [you can set a flag to log this in the event log].

If somehow that part 2b is going into say a buffer and glitchy comms occurs, the server may have ticked the confirmation as having been sent and confirmed, whilst the client did not actually write the message into the control files. Index out of sync, no mechanism in place to do a clean-up other then doing a project reset, run dry or JDI [With FAHB(edam) that will give the near perfect 'up to the checkpoint' credit, at least I hope that if say 7 of 10 10K blocks were trickled up, an abort/reset will initiate a grant through 7 and the generation of a new task starting at 8.] At least, I don't have the time or the will too sit there watching till a queue has been run dry and then reset. That looses, on average, as much computing time as the JDI approach.

Cannot remember having seen 'ghost' upload files, but do remember Ready to Report, albeit, what version of client is this? Cleanup has improved and seen 'already reported' type of messages in 7.4 or 7.6.