Skip to content

fix: commit migration write in get_shared_value to stop recurring md5 deprecation warning - #42916

Open
eschutho wants to merge 1 commit into
apache:masterfrom
eschutho:fix/md5-shared-value-migration-commit
Open

fix: commit migration write in get_shared_value to stop recurring md5 deprecation warning#42916
eschutho wants to merge 1 commit into
apache:masterfrom
eschutho:fix/md5-shared-value-migration-commit

Conversation

@eschutho

@eschutho eschutho commented Aug 8, 2026

Copy link
Copy Markdown
Member

Summary

Production logs show a recurring deprecation warning: The 'md5' HASH_ALGORITHM is deprecated and retained only for backwards compatibility; prefer 'sha256' for namespace generation. (superset/key_value/utils.py:94), firing on every call instead of only during a one-time migration.

Root cause

get_shared_value() looks up a value under the current hash-algorithm namespace and, on a miss, falls back to legacy algorithms (HASH_ALGORITHM_FALLBACKS, default ["md5"]). On a fallback hit, it's designed to migrate the entry to the current algorithm's UUID via KeyValueDAO.create_entry(...) so future lookups skip the deprecated fallback entirely.

KeyValueDAO.create_entry() only does db.session.add(entry) — it relies on the caller to commit. get_shared_value(), unlike its siblings set_shared_value() / upsert_shared_value() in the same file, was never wrapped in the @transaction() decorator that performs that commit. So the migration write was silently discarded on every call, and every subsequent lookup re-triggered the deprecated md5 fallback path forever instead of migrating once.

Change

Add @transaction() to get_shared_value(), matching the existing pattern already used by set_shared_value() and upsert_shared_value() in the same file. One line, additive only — no other logic changed.

No behavior change for the read path or for callers; this only makes the already-intended migration write actually persist.

Disclosure note: get_shared_value() is called standalone (outside any @transaction()) from the guest-token auth path (SecurityManager.get_guest_user_from_request_is_guest_token_revokedget_current_guest_token_revocation_version). After this fix, a fallback hit on that path now commits the entire current DB session, not just the migration write — the same "commits whatever's pending" exposure set_shared_value()/upsert_shared_value() have already had in this file for years, now extended to this function too. In practice this call happens early in request handling before other writes are queued, so no realistic unrelated-write risk, but flagging for reviewer awareness.

Decisions made that were not in the instructions

None.

Test plan

  • New regression test test_get_shared_value_commits_migration_to_current_algorithm in tests/unit_tests/key_value/test_shared_entries_migration.py: mocks superset.db.session.commit and asserts it's called once when a fallback hit triggers the migration write. Verified it fails pre-fix (AssertionError: Expected 'commit' to have been called once. Called 0 times.) and passes post-fix.
  • Full tests/unit_tests/key_value/ suite: 45/45 pass.
  • ruff check + ruff format --check: clean.
  • mypy on the changed file: zero errors attributable to it (pre-existing project-wide baseline noise only, unrelated).

… deprecation warning

get_shared_value() falls back to legacy hash algorithms and is designed to
migrate matched entries to the current algorithm's UUID via
KeyValueDAO.create_entry(), but the write was never committed: unlike its
siblings set_shared_value()/upsert_shared_value(), it wasn't wrapped in the
@transaction() decorator. The migration was silently discarded every call,
so the deprecated md5 fallback path fired on every subsequent lookup
instead of migrating once.

Add @transaction() to get_shared_value(), matching the existing pattern
used by its siblings in the same file.

Fixes the recurring "The 'md5' HASH_ALGORITHM is deprecated..." warning
seen in production logs (superset/key_value/utils.py:94).
@bito-code-review

bito-code-review Bot commented Aug 8, 2026

Copy link
Copy Markdown
Contributor

Code Review Agent Run #5b5cb4

Actionable Suggestions - 0
Filtered by Review Rules

Bito filtered these suggestions based on rules created automatically for your feedback. Manage rules.

  • superset/key_value/shared_entries.py - 1
    • Read-only function wrapped in transaction · Line 38-38
Review Details
  • Files reviewed - 2 · Commit Range: bcceab6..bcceab6
    • superset/key_value/shared_entries.py
    • tests/unit_tests/key_value/test_shared_entries_migration.py
  • Files skipped - 0
  • Tools
    • MyPy (Static Code Analysis) - ✔︎ Successful
    • Astral Ruff (Static Code Analysis) - ✔︎ Successful
    • Whispers (Secret Scanner) - ✔︎ Successful
    • Detect-secrets (Secret Scanner) - ✔︎ Successful

Bito Usage Guide

Commands

Type the following command in the pull request comment and save the comment.

  • /review - Manually triggers a full AI review.

  • /pause - Pauses automatic reviews on this pull request.

  • /resume - Resumes automatic reviews.

  • /resolve - Marks all Bito-posted review comments as resolved.

  • /abort - Cancels all in-progress reviews.

Refer to the documentation for additional commands.

Configuration

This repository uses Superset You can customize the agent settings here or contact your Bito workspace admin at evan@preset.io.

Documentation & Help

AI Code Review powered by Bito Logo

@eschutho
eschutho requested a review from rebenitez1802 August 8, 2026 16:17
@codecov

codecov Bot commented Aug 8, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 66.41%. Comparing base (2548179) to head (bcceab6).

Additional details and impacted files
@@            Coverage Diff             @@
##           master   #42916      +/-   ##
==========================================
- Coverage   66.42%   66.41%   -0.01%     
==========================================
  Files        2857     2857              
  Lines      161293   161294       +1     
  Branches    37134    37134              
==========================================
- Hits       107133   107131       -2     
- Misses      52135    52137       +2     
- Partials     2025     2026       +1     
Flag Coverage Δ
hive 38.24% <100.00%> (+<0.01%) ⬆️
mysql 57.78% <100.00%> (+<0.01%) ⬆️
postgres 57.83% <100.00%> (-0.01%) ⬇️
presto 40.20% <100.00%> (+<0.01%) ⬆️
python 59.22% <100.00%> (-0.01%) ⬇️
sqlite 57.45% <100.00%> (+<0.01%) ⬆️
unit 100.00% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

CODEC = JsonKeyValueCodec()


@transaction()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: The transaction decorator makes this read helper commit every pending change in the current SQLAlchemy session whenever it is called outside an existing transaction. Read-only callers such as guest-token validation and retention-window resolution can therefore persist unrelated ORM mutations unexpectedly. Move the migration write into an explicitly scoped transaction or otherwise avoid committing unrelated session state from this read API. [api mismatch]

Severity Level: Major ⚠️
- ⚠️ Guest-token validation can commit unrelated session mutations.
- ⚠️ Retention-window reads can persist pending ORM changes.
- ❌ Partial request state may become durable unexpectedly.

Fix in Cursor Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** superset/key_value/shared_entries.py
**Line:** 38:38
**Comment:**
	*Api Mismatch: The transaction decorator makes this read helper commit every pending change in the current SQLAlchemy session whenever it is called outside an existing transaction. Read-only callers such as guest-token validation and retention-window resolution can therefore persist unrelated ORM mutations unexpectedly. Move the migration write into an explicitly scoped transaction or otherwise avoid committing unrelated session state from this read API.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
👍 | 👎

Comment on lines +179 to +180
mock_dao.create_entry.assert_called_once()
mock_commit.assert_called_once()

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggestion: The regression test only checks that create_entry and commit were called; it does not verify that the migration uses the current-algorithm UUID, the expected resource, value, and codec. An implementation that writes under the legacy UUID would still pass, so the test does not validate the migration behavior it claims to cover. Assert the complete create_entry call, including the expected current UUID. [possible bug]

Severity Level: Minor 🧹
- ⚠️ Migration regression coverage accepts an incorrect destination UUID.
- ⚠️ Future deprecated-algorithm lookups could continue indefinitely.
- ⚠️ Resource, value, or codec regressions remain undetected.

Fix in Cursor Fix in VSCode Claude

(Use Cmd/Ctrl + Click for best experience)

Prompt for AI Agent 🤖
This is a comment left during a code review.

**Path:** tests/unit_tests/key_value/test_shared_entries_migration.py
**Line:** 179:180
**Comment:**
	*Possible Bug: The regression test only checks that `create_entry` and `commit` were called; it does not verify that the migration uses the current-algorithm UUID, the expected resource, value, and codec. An implementation that writes under the legacy UUID would still pass, so the test does not validate the migration behavior it claims to cover. Assert the complete `create_entry` call, including the expected current UUID.

Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
👍 | 👎

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant