Record file hash mismatch

[gregscullard]

Detailed Description
Occasionally, the recordDownloader reports a mismatch between the previous hash contained in the (n) file and the hash of the (n-1) file. This only occurs when the downloader and the parser run together.

Actual Behavior
Ensure the t_application_status table is clear for the following status_values

update t_application_status set status_value = '' where status_code ='LAST_PROCESSED_RECORD_HASH';
update t_application_status set status_value = '' where status_code ='LAST_VALID_DOWNLOADED_RECORD_FILE';
update t_application_status set status_value = '' where status_code ='LAST_VALID_DOWNLOADED_RECORD_FILE_HASH';

Start the recordParser
Start the recordDownloader
Observe the output from the recordDownloader, it will eventually complain about mismatching hashes when there isn't.

If you stop the parser, clear the t_application_values table again and delete any downloaded files, then run the downloader alone, previously reported mismatches no longer occur. This proves that the file hash sequence is correct and the mirror node is incorrectly reporting errors.

Expected Behavior
There is no reported mismatch of hashes when the files themselves are perfectly fine. Only true mismatches are reported.

Environment:
N/A