I think you are confusing 2 different things and considering they are the same.
The hardware, the UART, requires that both ends are running at the same speed and that the Rx sees a single start bit, which commences with a change from high to low and lasts 1 bit long, [edit] about 4ms at 2400 Baud, as @sterretje says. correction, as @sterretje did NOT say, it lasts about 0.4ms at 2400 Baud [end of edit]. Next comes the data, the receiver does not care what the data is, it just samples the next 8 periods from the middle of the start bit and uses what it sees as the data. Then it samples the stop bit(s) and, if valid, puts the data in the hardware Rx register. When that happens an interrupt is generated to tell the Rx code, which you do not normally see or have anything to do with, to put the received byte in the receive buffer and do whatever else needs doing, such as incrementing the index of the Rx buffer.
If you mess with the above process, for example by disconnecting the wire, then maybe the Rx hardware will still see data it can put in the hardware Rx register, or maybe it won't. If it does see data there is nothing to say it is valid, it might be junk. All you can say about it is it passed the minimal checks the hardware carried out before accepting it as a valid byte for the hardware Rx register. If it does not see a valid (remember 'valid' means valid start and stop, what is in between those the hardware does not care) byte then it doesn't put it in the hardware receive register, doesn't raise the interrupt and the byte is lost.
The synchronisation of the above happens on a per byte basis and will work as long as the transmitter is sending bytes at the correct baud rate and there is a reliable connection to the receiver. After a loss of connection it should start working at the next good, complete byte.
Separately from all that, and I think you are confusing with the above, bytes appear in the receive buffer for you code to process. Maybe those bytes are valid, maybe not. Maybe there is a complete message there, maybe not. Your code has to analyse what it sees and determine if it can use the information it got or has to discard it because it is invalid for some reason. What counts as valid or not is down the your code and what you defined as valid data. You have to write code to check this. The hardware of the UART knows nothing of this.
Adding 10ms might have fixed the symptoms of the problem but it's a bodge. Doing that means you have not understood what is really going on and addressed the real problem. When you understand the real problem and dealt with it you will know a great deal more about serial communications, and communications in general.
A pedantic note on terminology: serial is generally said to be asynchronous because there is nothing to synchronise one end with the other, the start and stop bits are to tell the receiver that something is about to arrive and that transmission of that byte has finished. Apart from that restriction the data can arrive any time the transmitter wants to send it out. What is not generally said is that it is also plesiochronous because the clocks at each end are not in any way synchronised, they are independent of each other, they just happen to be set at roughly the same rate.
