As per discussion in the platform lane chat.

curious for @schrockn's thoughts but i think this is a reasonable amount of damage for the user upside

I think this will be fine - unless someone deploys this change in a helm upgrade that somehow doesnt take down dagit running cron.

if someone upgrade their user code but forgets to update the celery workers - how does this fail? We don't promise cross version compat so i think this "breaking" change is probably ok - as long as it fails in a clear way that someone knows what to do about it

your queue - re: conversations around the index opt in

to your queue

up

up

up

up

also make psycopg2 gevent friendly

up

test assets page - add PythonError

up

up

up

i reached out to known users and they said they were no longer using it

ya those discussions dont need to block this diff - I am not certain on the trade offs around losing tick based error reporting for this case, but if you feel good about it you can move forward

maybe add a CHANGES.md entry about the breaking config changes in this diff so it doesn't get missed

gogo

seems good to me - add some comments to [1] since its a bit clever whats going on

defer to @sashank

nice

i like the overall direction - will leave to those with stronger opinions for final choices

this week? next week? @catherinewu / @rexledesma do we have telemetry on this at all ?

big change - will redo summary

This makes sense to land right before 0.10.0 just to put the breaking change in a major release. Ahead of removing support we should probably update all these callsites except for the explicit back compat test

Any idea why we went with NullPool in the first place?

we might need a concept of long lived vs short lived on DagsterInstance to thread down to these places - this behavior is only really key in dagit's long lived copy

use feature flag to gate debug console logging