I have a module that uses a Python script to fetch data from an API via a wrapper (

omadb

). I have a test case with 2 reasonably long test sequences (~400bp). When I run the script inside the Nextflow module, it tends to fail with

400 Bad request ("sequence too short")

. When I run substantially identical code in a Python REPL inside a venv, everything works fine and I get a response. Versions are not identical (Python 3.11 vs 3.14), but nothing changed in these updates should change the outcome. I have added a debug print to the script to check if the sequence is read in correctly, and it is.

I don't follow, is it an external API and all that differs is the client code or is the API in that venv? If it's an external API, I'd start by mapping out the call parameters exactly. If the server is in the venv, I'd probably default to printf-debugging to figure out where the unexpected happens (but then I'm also a lot for working with mental models of things so those prints are for testing hypothesis).

It's an external REST API (omabrowser.org/api). I have been interacting with it using

requests

with URLs, but I am trying to port to the dedicated

omadb

package, which has a more comprehensive query builder and is kept up to date with all the requirements of the API. I am only passing a single value (the protein sequence) to the function call, everything else is added to the request by the package. I have checked that the sequence is complete and correct. I have also had a quick look at the code of the package and I don't see any obvious problems there, the URL should be built correctly. I could add debug prints to the package files in site-packages, but I want to try less advanced measures before that.

I assume it's a tlsed protocol so capturing the network traffic doesn't help? If you can inject root certificates easily, having an intercepting proxy to look at the traffic might be helpful.

I have managed to set up a proxy, but I am struggling to make Nextflow use its certificate. The solution suggested by AI does not help, and I am not enough of a network expert to figure it out myself

That's not networking :) But how will depend on how it's done, i.e. container, conda or something else.

I have Nextflow installed through Conda in a GitHub Codespaces VM. I have set up a mitmweb proxy. Nextflow (obviously) does not pick up the certificate on its own. After asking Gemini I tried some trickery with JVM certificate store, but that did not help. Do you know how to set this up?

You probably don't care about the nextflow monitoring process traffic. You can set things up in the

beforeScript

I think (possibly with variable whitelisting if you're using a container engine).

I'm getting somewhere. I have managed to set up the env variables inside the container, but for some reason mounting the directory with certificates using

-v

does not work (the directory is empty in the container)

Å

Have I said something incredibly dumb or has your keyboard freaked out?

My fault:)

Docker issue sorted, turns out Codespaces is Docker-based, so I needed to temporarily put some files in the pipeline directory. As usual, Docker-in-Docker is the root of all evil. Now time to work on the core issue

It really does sound like a iteration issue. I don't recall, did you have the same version of the client library in both setups or did they differ? I'd try checking the API documentation and likely wrapping the queries in a list or tuple.

I have the same yersion of the client library in both setups, versions of Python differ but that should not matter. Wrapping it in a list is the most obvious idea, and Gemini tries hard to convince me it is the solution, but that raises

Unhashable type: list

. While testing in the REPL, the normal string works as an input, both as a literal and a variable.

And you're sure you're calling things the same way? Most things that would take several would probably support a list, but you can e.g. test with a one-item tuple

("some string",)

. Or try with a

bytes

instead of a

str

, et.c.

You inspired me to check if what I was passing was actually a

str

, and of course it wasn't. The object was a

Bio.Seq.Seq

, which is particularly sneaky, since its

__repr__

looks like a normal string, and only

type()

can reveal its identity.

omadb

has no validation logic, so it fails silently and in unexpected ways. Wrapping the object in

str()

solves the problem