Hi community! I've a question about states after a...
# announcements
m
Hi community! I've a question about states after a job failed using Adswerve/target-bigquery. After a tap fails, the next run uses the START_DATE set in the config variable, instead of picking up the state that failed. I saw this note in the documentation (in the end of the page) that some loaders might interrupt the pipeline before meltano writes the state. Does this happen with the adswerve/target-bigquery?
d
Also "yield init state, so even if there is an exception right after we get proper state emitted": https://github.com/adswerve/target-bigquery/blob/master/target_bigquery/process.py#L22
But there may not be any initial state if the target fails pretty much immediately
If the failed pipeline run didn't emit any state, Meltano should ignore it when finding state for the next run, but in this case the target may have explicitly emitted
{}
leading Meltano to store it and think it was valid for the next run
Since that line I just linked to would emit
{}
ahead of any real state
So I'm thinking that's a bug in the target: it shouldn't output any state until it gets a real state message from the tap
Otherwise it's essentially resetting state entirely, as you're seeing
m
I didn't understand this message: "Since that line I just linked to would emit 
{}
 ahead of any real state" What do you mean by 'I just linked'?
m
This is the log in the run that fails, I thought it was emitting state
d
The problem is that
target-bigquery    | INFO Pushing state: {}
line in your logs
m
Ohh
Got it now!!
d
The target shouldn't be outputting any empty initial state, it should wait for the first real state coming from the tap
Apparently the target supports an
initial_state
setting, but if that isn't set, instead of assuming an initial state of
{}
, the target shouldn't emit an initial state at all
m
Understood, I'll open an issue in thir repo about it.
d
Sounds good!
m
Thanks a lot @douwe_maan 😄
d
Glad I could help 🙂