Not sure if related to <https://github.com/meltano...
# singer-tap-development
d
Not sure if related to https://github.com/meltano/meltano/issues/8763, but I'm running into a strange issue where I filter out the streams using config so that they don't get included in the catalog at all. When I run the tap by itself using --discover, I can see that the generated catalog is correct. However, when running it as part of
meltano run
, I'm seeing the tap.properties.json created with the entire catalog visible. How does meltano call the tap when
meltano run
is called? Is it the singer sdk that creates that tap.properties.json, or is it meltano somewhere?
v
If you run meltano in debug mode it'll show the exact calls to discovery it's making
e
I filter out the streams using config
Maybe you're missing the same config when calling
meltano run
?
How does meltano call the tap when
meltano run
is called? Is it the singer sdk that creates that tap.properties.json, or is it meltano somewhere?
Meltano calls
<tap> --discover
in a subprocess, so it's a bit of both. Are you using tap-mssql?
d
I am using a custom fork of tap-mssql of wintersrd variant. I'm actually at a slight loss as to how it happens, because I cannot repro it with 100% success. I had already changed the executions to be synchronous, so it shouldn't be the parallelization issue from before.
Meltano calls
<tap> --discover
in a subprocess, so it's a bit of both.
Does this subprocess inherit the env variables of the parent process, or does it only look at the .env file?
Okay, so I think it is related to how discover is being called. The way that I'm calling meltano is by creating a subprocess that is passed over an env using Popen's env parameter. This seems to be respected on the sync step, but not the discover. That would also explain why it works when I try running it in debug, since I use the .env file directly in those cases, but my pipeline is not using the .env file
That seems very odd, though, because I would think that the code that calls this would be common and shared, regardless of which step of the run it's on.
It seems like this dump command doesn't seem to pass the env?
Sorry guys, PEBCAK. I need to stop the weekend night coding I think. I accidentally rolled back the part that set the env variable, but it was still printing the variable. Seems like a good reason to improve the implementation as well to read the few variables from the env instead of printing the added ones separately.
👍 1