Curious how those here handle retries? I see in the helm chart there is a

dagsterDaemon.runRetries

, but that seems a bit heavy handed. Is there a way to set retries on the materialization/sync of Airbyte assets specifically?

this might require https://github.com/dagster-io/dagster/pull/10150 to be merged first, unless there’s a workaround that @chris and @sandy might know of

Thanks - I’ll keep my eyes out for that release. The dagit retry policy will be sufficient for now

@Dusty Shapiro two things to add: • make sure your airbyte connection is retry safe. Some incremental sources (I.e. databases in CDC mode) can’t always go back to the original checkpoint on the next try • Airbyte has retry configuration as well for sync jobs. It’s set via an env var. not sure if they have exposed that in their new helm charts (we’re still using a deployment based on the original charts…that they mostly rewrote)

Good stuff, thanks @Adam Bloom. We’re still doing full refresh - overwrite in Postgres, so it’s been good so far.

@Dusty Shapiro that’s good feedback - we have

Backoff

and

Jitter

supported for op retries. might be nice to have those delay controls at the run level