chore(deps): bump the minor-patch-updates group with 3 updates

[dependabot]

Bumps the minor-patch-updates group with 3 updates: alembic, bugsnag and sqlalchemy.

Updates alembic from 1.19.2 to 1.20.0

Release notes

Sourced from alembic's releases.

1.20.0

Released: September 11, 2026

usecase

• [usecase] [batch] Added a warning for the case where an unnamed CHECK constraint on a reflected table is omitted from a batch "recreate" operation. An unnamed CHECK constraint can't be reliably carried over in a batch recreate as it may refer to columns that are being dropped or changed. This omission was previously a silent operation. The presence of any ~sqlalchemy.schema.CheckConstraint in Operations.batch_alter_table.table_args is taken to indicate that the case has been accommodated, and no warning is emitted.

  References: #1846

• [usecase] [autogenerate] Autogenerate now renders a warning comment above any rendered Operations.drop_constraint() directive for which the constraint name is None, as is the case when a constraint that has no name in the model is dropped, most typically within the downgrade() function of a migration that adds an unnamed constraint. A warning is also emitted on the console when the migration script is generated. The directive requires a non-None name in order to be able to emit a "DROP CONSTRAINT" command.

  References: #916

bug

• [bug] [batch] Fixed bug in batch mode where adding a column with a type that generates its own CHECK constraint, such as ~sqlalchemy.types.Boolean or ~sqlalchemy.types.Enum with ~sqlalchemy.types.Boolean.create_constraint set to True, would emit the constraint twice when the table was recreated, once under the name generated by the naming convention in use and once under the name given to the type. The constraint is now emitted once, using the same name that would be used outside of batch mode.

  References: #1768

• [bug] [batch] Fixed bug in batch mode where a CHECK constraint generated by a type such as ~sqlalchemy.types.Boolean or ~sqlalchemy.types.Enum would lose the name established for it by the naming convention in use when the table was recreated, as the constraint was regenerated against the temporary table used for the recreate operation. The naming convention is now resolved against the name of the table being replaced.

... (truncated)

Commits

• See full diff in compare view

Updates bugsnag from 4.9.1 to 4.9.2

Updates sqlalchemy from 2.0.52 to 2.0.54

Release notes

Sourced from sqlalchemy's releases.

2.0.54

Released: September 15, 2026

platform

• [platform] [change] Binary wheels are no longer built for Python 3.7. PyPI now rejects wheel files whose filename does not begin with the normalized project name, and the packaging tools that can be installed on Python 3.7 do not produce such a filename. As a result, SQLAlchemy 2.0.44 was the last release to publish Python 3.7 wheels to PyPI, and releases 2.0.45 and later have been available on Python 3.7 only as a source distribution; the wheel builds for Python 3.7 are now removed. Python 3.7 remains supported by the 2.0 series.

• [platform] [bug] Fixed issue where the Cython extensions were compiled without the freethreading_compatible directive, so that they did not declare themselves as safe to run without the GIL. On a free-threaded Python interpreter such as Python 3.13t or 3.14t, importing SQLAlchemy would cause the interpreter to re-enable the GIL, emitting a RuntimeWarning. The directive is now set when building for Python 3.13 and above, and a test has been added which confirms that importing SQLAlchemy on a free-threaded build does not enable the GIL.

  References: #13592

2.0.53

Released: September 14, 2026

orm

• [orm] [bug] Fixed issue where an expression passed to _orm.with_expression() that embedded a _sql.select(), such as a correlated _sql.exists(), would fail to populate the attribute correctly on the second and subsequent executions of an otherwise identical statement, when the _orm.query_expression() attribute was loaded by a relationship loader that emits a second query, i.e. _orm.selectinload(), _orm.lazyload() or _orm.immediateload().

  References: #13560

• [orm] [bug] Fixed memory issue where mapped classes, along with their Table and _orm.Mapper objects, would not be garbage collected after the _orm.registry in which they were mapped had been disposed and dereferenced. The issue would occur for mappings that made use of _orm.relationship() together with constructs such as an

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions