Finding
compute_file_hash at opensubtitles.rs:25 implements the OpenSubtitles-specific file hash (XOR of file-size plus the first and last 64 KB read as 8-byte little-endian u64 chunks). It is a public function and is the primary signal for high-quality subtitle matches: a hash match scores 1.0 versus 0.75 for title-only matches. The file's #[cfg(test)] block contains no tests for this function.
Evidence
crates/prostheke/src/providers/opensubtitles.rs:25:
pub fn compute_file_hash(path: &Path) -> std::io::Result<String> {
No test in the module exercises this function — neither the small-file path nor the tail-seek (SeekFrom::Start(file_size - 65536)) path is covered.
Why this matters
The OpenSubtitles hash algorithm is precisely specified: it must produce a 16-character hex string matching the server's expected value. Any deviation (wrong byte order, off-by-one on the 64 KB boundary, wrong seed value) silently produces the wrong hash, hash-match results stop appearing, and subtitle quality degrades from 1.0 to 0.75 with no error raised. The defect is indistinguishable from "no hash-matched subtitles available for this file" in normal operation, so it can persist undetected. On a counter-surveillance phone OS, a silently-degraded subtitle-matching path is a correctness regression that ships without a failing signal — exactly the class of latent defect tests exist to trap.
Desired correction
Add at least two tests: one with a known small file (fewer than 64 KB) and a pre-computed expected hash, and one with a file large enough to exercise the tail-seek path (greater than 64 KB). Compute the expected hashes independently using the published OpenSubtitles algorithm spec or the reference implementation.
Done when: compute_file_hash has tests for both the small-file (no tail seek needed) and large-file (tail-seek exercises SeekFrom::Start(file_size - 65536)) paths, with the expected hash values verified against an independent implementation.
Finding
compute_file_hashatopensubtitles.rs:25implements the OpenSubtitles-specific file hash (XOR of file-size plus the first and last 64 KB read as 8-byte little-endian u64 chunks). It is a public function and is the primary signal for high-quality subtitle matches: a hash match scores1.0versus0.75for title-only matches. The file's#[cfg(test)]block contains no tests for this function.Evidence
crates/prostheke/src/providers/opensubtitles.rs:25:No test in the module exercises this function — neither the small-file path nor the tail-seek (
SeekFrom::Start(file_size - 65536)) path is covered.Why this matters
The OpenSubtitles hash algorithm is precisely specified: it must produce a 16-character hex string matching the server's expected value. Any deviation (wrong byte order, off-by-one on the 64 KB boundary, wrong seed value) silently produces the wrong hash, hash-match results stop appearing, and subtitle quality degrades from
1.0to0.75with no error raised. The defect is indistinguishable from "no hash-matched subtitles available for this file" in normal operation, so it can persist undetected. On a counter-surveillance phone OS, a silently-degraded subtitle-matching path is a correctness regression that ships without a failing signal — exactly the class of latent defect tests exist to trap.Desired correction
Add at least two tests: one with a known small file (fewer than 64 KB) and a pre-computed expected hash, and one with a file large enough to exercise the tail-seek path (greater than 64 KB). Compute the expected hashes independently using the published OpenSubtitles algorithm spec or the reference implementation.
Done when:
compute_file_hashhas tests for both the small-file (no tail seek needed) and large-file (tail-seek exercisesSeekFrom::Start(file_size - 65536)) paths, with the expected hash values verified against an independent implementation.