N characters introduced into *indels.csv

Description of the bug

Hi, I’ve just run crisprseq using the targeted pipeline with a read1.fastq.gz only. I heavily quality filtered the input reads, removing any reads containing N characters. In the output indels.csv, there are many cases of N characters being reported in the "pre_ins_nt", "ins_nt" and "post_ins_nt" columns. When I check these reads in the input fastq file, the reported N characters are [ACGT] characters with Q value > 30. For the handful of reads I’ve looked at with these reported N characters, the majority called insertion (normal ACGT sequence) can be found in the input sequence, further suggesting these N calls could be erroneous results. My data is confidential so I unfortunately cannot share it. However, I notice that in the test dataset output, there are N's reported in some of the insertion outcomes which don't occur in the input reads, eg M00724:1:000000000-DC7GJ:1:1102:19229:3583 in hCas9-TRAC-a_R*.fastq.gz - this has AGA-N-CAT.

Command used and terminal output

No response

Relevant files

No response

System information

No response

Start with the targeted pipeline and inspect how the indels.csv columns pre_ins_nt, ins_nt, and post_ins_nt are produced. Compare the cited test-dataset read, M00724:1:000000000-DC7GJ:1:1102:19229:3583, against hCas9-TRAC-a_R*.fastq.gz and its AGA-N-CAT output. Done means the source of the N calls is explained and the reported sequence agrees with the input or the behavior is documented as expected.