ENG-1976: Support blocking on redis lock acquisition

[adamsachs]

Ticket ENG-1976

Description Of Changes

Support blocking lock acquisition with our redis_lock context manager, which allows callers to implement a 'blocking lock' with a blocking_timeout that can be specified.

This is needed for https://github.com/ethyca/fidesplus/pull/2786, in which we want to gate monitor task queueing so that it can't happen concurrently across a cluster of webservers.

Code Changes

• add args for blocking and blocking_timeout to our redis_lock context manager, default to False and 0 to keep existing behavior as-is
• fall back to the lock timeout if no blocking_timeout is provided

Steps to Confirm

1. See https://github.com/ethyca/fidesplus/pull/2786 for steps to confirm how this is actually being used in practice

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • Ensure that your downrev is up to date with the latest revision on main
  • Ensure that your downgrade() migration is correct and works
    • If a downgrade migration is not possible for this change, please call this out in the PR description!
  • No migrations
• Documentation:
  • Documentation complete, PR opened in fidesdocs
  • Documentation issue created in fidesdocs
  • If there are any new client scopes created as part of the pull request, remember to update public-facing documentation that references our scope registry
  • No documentation updates required

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

2 Skipped Deployments

Project	Deployment	Preview	Comments	Updated (UTC)
fides-plus-nightly	Ignored	Preview		Nov 14, 2025 9:23pm
fides-privacy-center	Ignored			Nov 14, 2025 9:23pm

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.10%. Comparing base (ce27594) to head (3983e88).
⚠️ Report is 21 commits behind head on main.

❌ Your project status has failed because the head coverage (82.10%) is below the target coverage (85.00%). You can increase the head coverage or adjust the target coverage.

❗ There is a different number of reports uploaded between BASE (ce27594) and HEAD (3983e88). Click for more details.

HEAD has 18 uploads less than BASE

Flag	BASE (ce27594)	HEAD (3983e88)
	32	14

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6961      +/-   ##
==========================================
- Coverage   87.32%   82.10%   -5.23%     
==========================================
  Files         525      525              
  Lines       34418    34458      +40     
  Branches     3960     3967       +7     
==========================================
- Hits        30055    28291    -1764     
- Misses       3500     5346    +1846     
+ Partials      863      821      -42     

☔ View full report in Codecov by Sentry.
📢 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.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR adds blocking lock acquisition support to the redis_lock context manager. The implementation adds two optional parameters (blocking and blocking_timeout) with sensible defaults that maintain backward compatibility with all existing usages.

Key changes:

• Added blocking parameter (defaults to False to preserve existing non-blocking behavior)
• Added blocking_timeout parameter with intelligent fallback to timeout when not specified
• Added comprehensive parametrized tests using mocks to verify correct parameter passing

Observations:

• The fallback logic (using lock timeout as blocking_timeout when blocking=True and blocking_timeout=0) is reasonable and prevents indefinite blocking
• All 6 existing usages of redis_lock in the codebase remain compatible
• Test coverage validates parameter passing but uses mocks rather than testing actual blocking behavior with Redis

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The implementation is straightforward, maintains backward compatibility with all existing usages, includes sensible defaults and fallback logic, and has test coverage validating the parameter passing behavior
• No files require special attention

Important Files Changed

File Analysis

Filename	Score	Overview
src/fides/api/util/lock.py	5/5	Added blocking and blocking_timeout parameters to redis_lock with sensible defaults and fallback logic
tests/ops/util/test_lock.py	4/5	Added parametrized tests to verify blocking parameters are passed correctly, but missing integration test for actual blocking behavior

[greptile-apps]

_{2 files reviewed, no comments}

_{Edit Code Review Agent Settings | Greptile}

[vcruces]

Why is blocking_timeout set to 0 by default instead of None, which is the default for Lock?

I'm asking because previously, when blocking was False, we didn't send a blocking_timeout at all (which is effectively the same as sending None, matching the default behavior of Lock).

Is the goal to preserve the original behavior, or do we specifically want blocking_timeout=0 now?

[adamsachs]

yeah no good reason, i don't think this technically mattered but it did read strangely, so i adjusted to default to None in 8401e29!

[adamsachs]

thanks for the close eye 👍