https://dagster.io/ logo
Join Slack
Powered by
getting `dagster.core.errors.DagsterLaunchFailedEr...
# announcements
c
getting 
dagster.core.errors.DagsterLaunchFailedError: Host <http://localhost:3000> failed sanity check. It is not a dagit server.
after upgrading to 0.7.7
s
You need to be running dagit if you’re using the 
RemoteDagitRunLauncher
c
yeah it's running
s
And it’s running on :3000 not :3333 right
c
right
s
Hmm trying to repro
c
it seems like clicking "launch execution" might be crashing something - it becomes unresponsive right after i click that, eg if i try refreshing the page, it sort of takes a minute to load
but i don't see anything in the logs
also noticing it takes longer to boot up than before
m
@Chris Roth did you run 
dagster instance migrate
?
c
yep
s
Was able to repro - thanks for catching this. Taking a look at the fix
c
cool! thank you for taking a look and glad it's not just my imagination 😛
hm also getting 
alembic.script.revision.ResolutionError: No such revision or branch
after reverting back to 0.7.6
looks migration related
still in the staging phase with this thing, so could just delete the dagster db and re-create it if needed
is it possible to reverse a migration?
s
cc @max, @prha
c
something weird is going on here - i downgraded to 0.7.6 and started with a fresh database but still getting the error
p
@Chris Roth just to confirm, you’re configuring the 
RemoteDagitRunLauncher
on dagit to launch runs against itself?
c
yeah. i'm actually having some weird issue that makes me think it might be an issue on my end - gimme a min to debug
p
I can definitely repro, though
just not 100% positive if this is a new breakage or an old breakage, because I haven’t run through this flow before
c
i thought maybe it could be that one of my env variables changed but just confirmed that it's not that either
it smells like sub-dependency version issue to me
because nothing else has changed
is it possible that a minor version didn't get pinned down somewhere in pip or npm and maybe that is causing it?
p
yes, definitely… we tend not to pin versions because we can’t predict what requirements folks downstream will have
c
makes sense
hm
p
yeah, we don’t have a test at the moment for this specific flow
c
i think i found the issue
yesterday i added:
Copy code
dagit:
  execution_manager:
    disabled: True
    max_concurrent_runs: 25
when i remove that from dagster.yaml it fixes it!
p
interesting
c
actually, this kind of makes sense, i guess
it's specifically the 
disabled: True
line
p
hmm, and this is on 
0.7.6
?
c
0.7.6 and 0.7.7
the docs say 
# whether dagit can run pipelines in a sub process
this makes sense though - maybe this is not a bug
p
right…. having that disabled will remove the 
Start Execution
option from dagit
c
damn, i feel stupid
hah
p
well, I can still repro on 0.7.7 without the disabled flag, so I’ll keep digging in, but good to know that you can work around it
Just for curiosity’s sake… what’s the main purpose of launching vs starting an execution on the local dagit
c
yeah the fact that you can reproduce is curious
i'm launching via celery workers for the most part
but on local machine finding it easier to work when they just run on the dagit instance
p
got it
s
@Chris Roth if you click on this dropdown you can switch over to 
Start Execution
You don’t want to be using the 
RemoteDagitRunLauncher
when executing in Dagit locally
c
cool, i think we're good then
sorry about the confusion here
and also thank you guys again for all the help, you are amazing
can't believe how hard you guys work
❤️ 1
p
aw shucks
btw, it’s totally fine to have the remote dagit run launcher configured
but i don’t think it will work to actually launch runs against itself
as long as the 
disabled
flag is not on, you should have the option of starting, rather than launching
c
yeah the only reason i have it enabled is for launching pipelines from another pipeline haha
🦜 1
m
that's very cool
i would love to hear more about that
Open in Slack
PreviousNext
Powered by