Wrap iterator in tighter error bound, fix some messages

I'm ambivalent about pipeline_failure_sensor. I think it's nice that it exposes the underlying implementation, but not sure if we want to lock in the expectation that we support the same signature for the user function as you would a regular sensor evaluation function.

I'm ambivalent about pipeline_failure_sensor. I think it's nice that it exposes the underlying implementation, but not sure if we want to lock in the expectation that we support the same signature for the user function as you would a regular sensor evaluation function.

What about @pipeline_failure_sensor? @alangenfeld might also have opinions.

This is looking pretty good to me. Not sure about the naming, but don't have great alternatives (pipeline_failure_watcher? watch_pipeline_failure?).

Yep, I agree with @sandyryza... It's nice that we can distinguish between skip ticks (no runs failed) vs successfully ran monitor function ticks (reported into failed run), but it'd be nice to be able to do that without using the same UI that other sensors use for run requests. What would the UI look like if we did a retry request?

It seems like these runs could be interpreted as runs that were triggered by the sensor - how do we expect users to tell the difference?

maybe add a DagsterInvalidInvocationError for when the wrong info is passed?

works for me !

rebase

cursor -> before_cursor
+ ascending=False

mypy

naming spitballing:

• pipeline_failure_sensor / pipeline_sensor which means it watches pipelines - accurate, no new noun
• pipeline_failure_monitor / pipeline_monitor which creates a new noun "monitor" but the name "monitor" is more intuitive as it describes the use case not the machinery

base decorator

+ MonitorRequest

This looks pretty nice. A couple naming questions:

• If a monitor ultimately boils down to a sensor, is it worth introducing a new noun? I.e. should we just call this pipeline_failure_sensor?
• We probably will want to add a version that monitors / senses failures for a particular pipeline or set of pipelines. How do we imagine the name of that fitting in with the name of this API?

+ is_monitor_sensor flag

That would work too - the most important thing to me is that you’re able to
paginate in a forwards direction with a limit

rebase

Add more tests for multi-output case, change arg names

to make sure im understanding it correctly, say we have runs = [1,2,3,4,5,6,7,8,9,10] and we will get:
get_runs(cursor=5, ascending=True, limit=2) = [6,7] where cursor is an after cursor
get_runs(cursor=5, ascending=False, limit=2) = [2,1] where cursor is a before cursor

per offline discussion with @rexledesma - these events won't be persisted in OSS for now so should be safe to land - if we ever need to update we can run migration on our end.
i'd recommend stack the call site diff and make sure the new events are working properly before landing :)

@yuhan The call site would be in the monitoring daemon. Initially this was for the prototype, which is why ALERT_FAILURE was not included, but will do so now.

Goal here seems very reasonable. Question for you and other reviewers - Would adding an ascending=True/False flag be another way to deal with this? (i.e. the same cursor could be either a before_cursor or after_cursor depending on the order that you want the results)?

fixing outputs

In D7832#206156, @sandyryza wrote:

It seems like this is a strict improvement over what we currently have, so we should probably merge. That said, do we have an understanding of what happened to this data that we're now missing? Did dbt stop producing it entirely? Is there a different JSON file that contains it?

black

up

TODO:

• allow query multiple types: +DagsterEventType.PIPELINE_INIT_FAILURE
• yield something to indicate the monitor success/error instead of "skipping"