chroma-core/chroma · error · InvalidHashError
Invalid hash algorithm specified: {alg}
Error message
Invalid hash algorithm specified: {alg} What it means
Raised by _read_migration_file when the hash_alg argument is neither 'md5' nor 'sha256' (chromadb/db/migrations.py:267) — InvalidHashError. It guards the config value that decides how migration SQL is hashed for consistency checks, and fires before any SQL is read or applied.
Source
Thrown at chromadb/db/migrations.py:267
def _read_migration_file(file: MigrationFile, hash_alg: str) -> Migration:
"""Read a migration file"""
if "path" not in file or not file["path"].is_file():
raise FileNotFoundError(
f"No migration file found for dir {file['dir']} with filename {file['filename']} and scope {file['scope']} at version {file['version']}"
)
sql = file["path"].read_text()
if hash_alg == "md5":
hash = (
hashlib.md5(sql.encode("utf-8"), usedforsecurity=False).hexdigest()
if sys.version_info >= (3, 9)
else hashlib.md5(sql.encode("utf-8")).hexdigest()
)
elif hash_alg == "sha256":
hash = hashlib.sha256(sql.encode("utf-8")).hexdigest()
else:
raise InvalidHashError(alg=hash_alg)
return {
"hash": hash,
"sql": sql,
"dir": file["dir"],
"filename": file["filename"],
"version": file["version"],
"scope": file["scope"],
}
View on GitHub (pinned to aecdd12c8a)
Solutions
- Set the value to exactly 'md5' or 'sha256' (lowercase, no separators).
- If you wrote the config plumbing yourself, validate the setting at startup against the allowed set rather than letting it fail deep in migration loading.
- Upgrade Chroma if you expect a newer algorithm to be supported.
Example fix
# before find_migrations(dir, scope, hash_alg="sha-256") # InvalidHashError # after find_migrations(dir, scope, hash_alg="sha256")
Defensive patterns
Strategy: validation
Validate before calling
assert hash_alg in ("md5", "sha256"), f"Unsupported hash_alg: {hash_alg}" Try / catch
from chromadb.db.migrations import InvalidHashError
try:
find_migrations(dir, scope, hash_alg=alg)
except InvalidHashError:
alg = "md5"
find_migrations(dir, scope, hash_alg=alg) Prevention
- Restrict hash-alg config to the literal strings 'md5' or 'sha256'.
- Validate custom config at startup, not deep in migration loading.
- Cover config values with tests when you fork/extend migration settings.
When it happens
Trigger: Passing a migrations hash-algorithm setting/parameter with an unsupported value (anything other than the exact strings 'md5' or 'sha256', including case variants like 'MD5' or 'SHA-256'). This is plumbed through migration configuration internals, not the public client API.
Common situations: Custom deployments or forks that expose hash algorithm config and set it to 'sha512'/'sha-256'/uppercase variants; copy-pasted config snippets; code written against a newer/older Chroma that accepted different algorithm names.
Related errors
- Inconsistent hashes in {path}:db hash was {db_hash}, source
- No migration file found for dir {file['dir']} with filename
- The model name is required.
- Failed to fetch ${input} with status ${resp.status}: ${resp.
- The model name cannot be changed after initialization.
AI-assisted analysis of chroma-core/chroma@aecdd12c8a (2026-08-16).
Data as JSON: /api/errors/5b6e11f956bef9fd.
Report an issue: GitHub.