Troubleshooting #

I don’t know what to do after an error message #

Well, that’s below our targets, we want our error messages to tell you enough for you to be able to fix it.

Please file a bug report in our issue tracker.

I received a friendly panic message #

These look like this

Well, this is embarrassing.

mbf-fastq-processor had a problem and crashed. To help us diagnose the problem you can send us a crash report.

We have generated a report file at "/tmp/nix-shell.ty6dWk/report-89ffc0f3-8076-4f55-83f0-c0a5d2fb3b55.toml".

This kind of error message, which wraps a rust ‘panic’ only happens if mbf-fastq-processor has managed to get into an impossible or unforeseen state.

That’s always a bug (even on invalid input, the issue should be trapped by non-panic code).

Please review the temp file it’s created and attach it to an issue.

Ideally of course with a minimal data set that reproduces the crash, but just the traceback will tell us quite a bit.

The output isn’t what was expected #

Please prepare a minimal example for us to run, and what output you’d expect and submit an issue.

We’ll then see if it’s a bug, or a documentation issue.

I am running out of RAM. #

You can control the maximum RAM usage by reducing the number of blocks that may be concurrently processed.

To to so adjust the options.max_blocks_in_flight option down from it’s default of 100 blocks.

My use case needs a missing transformation / step #

While we have a large set of transformations, at times you need something special.

We have chosen not to add a generic ‘insert-javascript-to-mangle-reads-here’ transformation, because it’s difficult to make performant - and getting the transformations that turn out to be good ideas into mbf-fastq-processor would be hindered by the language mismatch between the core transformations (rust) and the user ones.

Instead, our documentation contains a guide on implementing a new transformation.