Meltano

image.png

After some digging <@U06CBKL5W7L>, I figured out the Airflow thing we talked about during community hours
Problem was it was a bit obtuse to get to it, I had to navigate into my venv and modify the meltano airflow wrapper plugin code just cuz the error was a bit of a red herring

Printing the stderror from the airflow subprocess, its painfully obvious what the problem is

The issue is the Meltano code around <https://gitlab.com/meltano/meltano/-/blob/master/src/meltano/core/plugin/airflow.py#L103|here> does _NOT_ actually bubble up or display the stderr during these subprocess invocations.
Even with log-level=debug, we just end up with a very large stack trace which bubbles up to `click` (not helpful)

All of these airflow invocations below *should log the stderr from the airflow* command, if not always --then at _least_ when log-level is debug.

1. The small CLI screenshot is my manual `print` statement 
2. The large CLI screenshot is what is currently logged (no airflow stdout)
3. The gitlab screenshot is where we should consider doing something with the stderr since airflows is _good_.

Also, side note, <https://gitlab.com/meltano/meltano/-/blob/master/src/meltano/core/plugin/airflow.py#L122|this> forced initdb in the primary entrypoint is blocking if your database is corrupted because you cant run `db reset` without it attempting `db init` which can fail in a way that a reset would resolve

We should bypass that on a reset db command