I just want to put a helpful note to everyone due to SqlAlchemy not being pinned on Dagster any new docker build will install sqlalchemy 2.0.0 which seems to be incompatible with dagster (well at least the version i'm using 1.1.7); my fix was explicitly tying my requirements.txt to sqlalchemy 1.4.5 which was the version running on the dagster daemon pod. I lost an afternoon to chasing down this issue. So I hope this message can help someone else from debugging this. For transparency and knowledge sharing this was the error I was receiving when trying to run

Traceback (most recent call last):
  File "/usr/local/bin/dagster", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.10/site-packages/dagster/_cli/__init__.py", line 48, in main
    cli(auto_envvar_prefix=ENV_PREFIX)  # pylint:disable=E1123
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1130, in __call__
    return self.main(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1055, in main
    rv = self.invoke(ctx)
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1657, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 1404, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/usr/local/lib/python3.10/site-packages/click/core.py", line 760, in invoke
    return __callback(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/dagster/_cli/api.py", line 74, in execute_run_command
    return_code = _execute_run_command_body(
  File "/usr/local/lib/python3.10/site-packages/dagster/_cli/api.py", line 100, in _execute_run_command_body
    instance.get_run_by_id(pipeline_run_id),
  File "/usr/local/lib/python3.10/site-packages/dagster/_utils/__init__.py", line 670, in inner
    return func(*args, **kwargs)
  File "/usr/local/lib/python3.10/site-packages/dagster/_core/instance/__init__.py", line 808, in get_run_by_id
    return cast(DagsterRun, self._run_storage.get_run_by_id(run_id))
  File "/usr/local/lib/python3.10/site-packages/dagster/_core/storage/runs/sql_run_storage.py", line 460, in get_run_by_id
    query = db.select([RunsTable.c.run_body, RunsTable.c.status]).where(
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/_selectable_constructors.py", line 493, in select
    return Select(*entities)
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/selectable.py", line 5219, in __init__
    self._raw_columns = [
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/selectable.py", line 5220, in <listcomp>
    coercions.expect(
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/coercions.py", line 413, in expect
    resolved = impl._literal_coercion(
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/coercions.py", line 652, in _literal_coercion
    self._raise_for_expected(element, argname)
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/coercions.py", line 1143, in _raise_for_expected
    return super()._raise_for_expected(
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/coercions.py", line 711, in _raise_for_expected
    super()._raise_for_expected(
  File "/usr/local/lib/python3.10/site-packages/sqlalchemy/sql/coercions.py", line 536, in _raise_for_expected
    raise exc.ArgumentError(msg, code=code) from err
sqlalchemy.exc.ArgumentError: Column expression, FROM clause, or other columns clause element expected, got [Column('run_body', Text(), table=<runs>), Column('status', String(length=63), table=<runs>)]. Did you mean to say select(Column('run_body', Text(), table=<runs>), Column('status', String(length=63), table=<runs>))?

which to me is indicative of breaking changes in sqlalchemy to that of 1.4.5. I see this has been fixed in https://github.com/dagster-io/dagster/commit/7a0b7ccc1a55624c729d20a398ede7895dda23a9 so perhaps the simple solution is to upgrading your dagster release in your deployments and helm chart

Thanks Jonathan. We’re putting together a release right now to address this.

@prha if we have a package in our requirements that overlaps and is a later version than what you have in your newly implemented caps on dagster reqs, how is that handled? does ours get downgraded to your max capped version?

I think it depends on the pip resolver and the order of dep resolution (https://pip.pypa.io/en/stable/topics/dependency-resolution/, https://codingshower.com/pip-dependency-resolver-and-version-conflicts/). In general, this would cause a resolution error when you try to run

pip install

and you’d have to manually resolve somehow.