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.

fastqrab 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 fastqrab 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 fastqrab 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.