one more sensor issue but starting a new thread since it s d

Question

one more sensor issue but starting a new thread since it s definitely separate from the one we troubleshooted above I replaced a schedule with a sensor of the same name The sensor has a default schedule of `STOPPED` Oddity 1 it started as enabled the first time Which is likely related to oddity 2 I ve just enabled the sensor but it isn t ticking dagster daemon however is trying to tick the old schedule I m getting no logs from `SensorDaemon` with this sensor name but I am getting the following ` dagster daemon 559fb67f7f 4rhv8 dagster 2022 10 19 22 04 52 +0000 dagster daemon SchedulerDaemon WARNING Could not find schedule lt schedule sensor name gt in repository lt repo gt If this schedule no longer exists you can turn it off in the Dagit UI from the Status tab ` Dagit shows the sensor enabled and the status tab that log should be corrected to Overview now doesn t show a schedule that no longer exists I disabled them all earlier

Adam Bloom · Answer

obvious workaround is to change the sensor name but is this expected to not work

Adam Bloom · Answer

interestingly another sensor renamed from a schedule triggered correctly when enabled they re both partitioned jobs not sure what else is different between these

Adam Bloom · Answer

any reason to not just delete the impacted rows from the `instigators` table that would presumably cause them to re create correctly when I enable them next

Adam Bloom · Answer

need to drop from `jobs` as well but that worked I ll leave one less critical sensor in this broken state for now in case you need any more info but will proceed with forcing re creation on the others

chris · Answer

so you re saying that a different sensor renamed from a schedule worked correctly Did that one have default status enabled as well

Adam Bloom · Answer

default status for all of them was stopped I couldn t figure out the pattern to which ones cleared the old schedule correctly vs which still had a `SCHEDULE` type job instigator that needed to be manually cleared

Adam Bloom · Answer

The tick history carried over from the schedule to the sensor with the rename but for my use case I m honestly not opposed to that the purpose of the ticks is to trigger the same job so the context is correct

Adam Bloom · Answer

I ve still got some sensors in that state in the database although not sure what information we can extract from that Just an FYI I only manually dealt with the handful that I needed to get started at the end of day yesterday overnight triggers

chris · Answer

i see that makes sense Definitely an artifact of some sort from having same name schedules + sensors and switching between them we should certainly be handling that more gracefully Will try and repro on my own