How to resolve mixed messages during BLE Indication

[Chengxin Ma]

The task I am working on is sending a list of records from an nRF52832 chip to a central. Before sending the records, the total number of them should be sent, so the central device would know how many records it is expected to process.
The communication is triggered by turning on the indication. On the SoC side, this raises a BLE_GATTS_EVT_WRITE event, under which the number of records is sent using sd_ble_gatts_hvx(). Since this moment on there will be BLE_GATTS_EVT_HVC events, under which the records are sent piece by piece (upon getting a confirmation from the central) until the end.
When a disconnection happens, ideally on the central side it would receive a messages sequence like:

00-50-00-00-00-00; // number of records in hex format; 50(hex) = 80(dec)
A0-B0-C0-D0-E0-F0; // from here on is the testing data
1A-1B-1C-1D-1E-1F;
2A-2B-2C-2D-2E-2F;
3A-3B-3C-3D-3E-3F;
// here comes a disconnection
00-4C-00-00-00-00; // resend the number of records in the hex format; 4C(hex) = 76(dec)
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;
...

However, what I actually got is:
00-50-00-00-00-00;
A0-B0-C0-D0-E0-F0;
1A-1B-1C-1D-1E-1F;
2A-2B-2C-2D-2E-2F;
// here comes a disconnection
00-4C-3C-3D-3E-3F; // unexpected piece of record
4A-4B-4C-4D-4E-4F;
5A-5B-5C-5D-5E-5F;
...

As we can see, 00-4C-3C-3D-3E-3F is a combination of 3A-3B-3C-3D-3E-3F and 00-4C-00-00-00-00.
I am wondering why these two messages are put together.
The intuitive hypothesis is that there is some kind of sending/receiving buffers that are not cleared after a disconnection.
Does such a hypothesis make sense? If yes how can I solve this problem of mixed messages?
The following screenshots show the message sequence received by the phone. In the second picture, the number of total messages/records is not displayed after the first enablement of indication, and after the second enablement of indication, the message starting with "4A" is missing.
Screenshot_20160912-121046.png Screenshot_20160913-151849.png

[Hung Bui]

"3A-3B-3C-3D-3E-3F" missing because it was queued and updated in the value of the characteristic but the indication has not been successfully received and confirmed. You should base on the confirmation event before you update the new value. So if "3A-3B-3C-3D-3E-3F" is not confirmed it should be resent when you connected again.

Can you explain further why sending full 6 bytes of the total number of records would solve (if it really solves) the problem of the missing message?

It's pretty simple, if you have fixed size characteristic 6 bytes for example, and you call hvx command to update only 2 bytes, the other 4 bytes won't change. The whole 6 bytes will be sent in the indication packet. And what the central receives are 6 bytes with 2 first bytes has new value and last 4 bytes have old value. If you call hvx command with 6 bytes, the whole 6 bytes will be updated and you don't have problem of mixing old and new value.