Тихо неправильные данные хуже упавшего скрипта
Скрипт, который упал, вы почините за пять минут. Скрипт, который отработал молча и выдал неправильный ответ, вы не почините никогда, потому что не узнаете, что он сломан.В работе с FASTA и FASTQ таких мест неприлично много. Почти все они когда‑то были задуманы как удобство.Вот три, с которыми я сталкивался чаще всего.Первое. Инструмент пишет FASTQ, а качества у записи нет. Вместо ошибки он подставляет строку из I. Файл получается валидный, парсер доволен, а фильтр по качеству дальше по пайплайну видит идеальные риды и пропускает всё подряд.Второе. R1 и R2 разъехались: один файл отфильтровали, второй забыли. На выходе абсолютно корректный FASTQ, просто риды спарены не с теми. Формат не нарушен ни в одном байте. Ни один валидатор не возразит.Третье. Определение Phred‑кодировки по образцу, который одинаково хорошо подходит и под Phred+33, и под Phred+64. Инструмент молча выбирает вариант. Иногда правильный.Общее у всех трёх одно: вместо ошибки вы получаете правдоподобный результат. И это худший из возможных исходов, потому что ошибку вы бы заметили.Полгода назад я начал писать fastx, библиотеку и CLI для FASTA/FASTQ на Rust. Основное решение в ней сформулировано так: там, где можно либо угадать, либо признать неоднозначность, признавать неоднозначность. Как это устроено