diff --git a/keystone/common/sql/upgrades.py b/keystone/common/sql/upgrades.py
index c45993bfc2..91a11995b4 100644
--- a/keystone/common/sql/upgrades.py
+++ b/keystone/common/sql/upgrades.py
@@ -231,8 +231,9 @@ def offline_sync_database_to_version(version=None):
 
 def get_db_version(repo=LEGACY_REPO):
     with sql.session_for_read() as session:
+        repo = find_repo(repo)
         return migration.db_version(
-            session.get_bind(), find_repo(repo), get_init_version())
+            session.get_bind(), repo, get_init_version(repo))
 
 
 def validate_upgrade_order(repo_name, target_repo_version=None):
diff --git a/releasenotes/notes/bug-1844157-7808af9bcea0429d.yaml b/releasenotes/notes/bug-1844157-7808af9bcea0429d.yaml
new file mode 100644
index 0000000000..29e19cc487
--- /dev/null
+++ b/releasenotes/notes/bug-1844157-7808af9bcea0429d.yaml
@@ -0,0 +1,13 @@
+---
+fixes:
+  - >
+    [`bug 1844157 <https://bugs.launchpad.net/keystone/+bug/1844157>`_]
+    When performing `keystone-manage db_sync --check` if the legacy repo
+    started at the same version number as the expand/contract/migrate
+    repos the check to see if the db was under version control failed
+    indicating that the db was up-to-date. This was due to the function
+    `get_init_version` never receiving the path for the repo queried for
+    version information. The fix is to ensure the repo path is always
+    passed to get_init_version from the
+    `keystone.common.sql.upgrade.get_db_version` function.
+