This is related to the work in
WT-3276. If corruption is added to the end of an otherwise clean log file that will be used in recovery (i.e. past the checkpoint), the corruption is ignored, recovery completes and all records are visible. This is the current behavior without any changes for WT-3276. Recovery should in fact fail, and salvage should truncate the log at the point of corruption. In another case, when corruption occurs in a preallocated, but not yet used, part of a log file, it is not detected. It does result in a log file "hole", which sets the end point for recovery (no records past that point are used). But it is better for a real corruption to cause a visible failure.
The work for
WT-3276 contains a new test_txn19.py that has NOTE: comments to highlight the trouble areas.