Ints 334 bazaarvoice allow optional return on polling override

[Vagoasdf]

Ticket INTS-334

Description Of Changes

Allows for Optional Poling results on Request overrides for polling access requests.

Code Changes

• Added Optional as a possible return for Access Polling overrides
• Added check on sub requsts results for empty results to avoid errors

Steps to Confirm

1. Pair with https://github.com/ethyca/fidesplus/pull/2712
2. Create an access request with a random email (I.E empty@ethyca.com)
3. Wait for the access request to end
4. The Privacy request should be empty and should not error out

Tests for this path are present on the Paired PR, for the none-data on access

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.

Project	Deployment	Preview	Comments	Updated (UTC)
fides-plus-nightly	Ready	Preview	Comment	Oct 31, 2025 1:55pm

1 Skipped Deployment

Project	Deployment	Preview	Comments	Updated (UTC)
fides-privacy-center	Ignored			Oct 31, 2025 1:55pm

[codecov]

Codecov Report

❌ Patch coverage is 14.28571% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.47%. Comparing base (44024ab) to head (a6b3a2c).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
...async_dsr/strategies/async_dsr_strategy_polling.py	0.00%	5 Missing ⚠️
...vice/saas_request/saas_request_override_factory.py	50.00%	1 Missing ⚠️

❌ Your patch status has failed because the patch coverage (14.28%) is below the target coverage (100.00%). You can increase the patch coverage or adjust the target coverage.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6887      +/-   ##
==========================================
- Coverage   87.47%   87.47%   -0.01%     
==========================================
  Files         523      523              
  Lines       34088    34090       +2     
  Branches     3916     3917       +1     
==========================================
  Hits        29820    29820              
- Misses       3412     3414       +2     
  Partials      856      856              

☔ 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

Allows polling access request overrides to return Optional[PollingResult] to handle cases where no data is available for access requests.

• Updated validate_polling_result_override_function to accept Optional[PollingResult] as valid return type
• Added null check in _process_completed_sub_request to skip result storage when polling result is None
• Sub-requests with empty results are marked complete but excluded from aggregation

Confidence Score: 4/5

• This PR is safe to merge with minor observability concerns
• The changes correctly implement optional polling results, but the implementation silently handles None values without logging, which could make debugging harder if override functions have bugs. The core logic is sound - empty results are properly excluded from aggregation.
• No files require special attention - changes are straightforward and localized

Important Files Changed

File Analysis

Filename	Score	Overview
src/fides/api/service/saas_request/saas_request_override_factory.py	5/5	Added Optional import and updated polling result override validation to accept Optional[PollingResult] return type
src/fides/api/service/async_dsr/strategies/async_dsr_strategy_polling.py	4/5	Added null check for polling results to handle empty responses, but sub-request completion logic may silently hide errors

_{2 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

style: this silently marks the sub-request as complete even when polling_result is None, which could hide bugs in override functions. consider logging when polling_result is None to distinguish between legitimate empty results and potential errors

Suggested change

	# Checks if we have a polling result, response could be empty in case there was no data to access
	if polling_result:
	# Ensure we have the expected polling result type
	if not isinstance(polling_result, PollingResult):
	raise PrivacyRequestError(
	"Polling result must be PollingResult instance"
	)
	# Store results on the sub-request
	self._store_sub_request_result(polling_result, sub_request, polling_task)
	# Store results on the sub-request
	self._store_sub_request_result(polling_result, sub_request, polling_task)
	# Checks if we have a polling result, response could be empty in case there was no data to access
	if polling_result:
	# Ensure we have the expected polling result type
	if not isinstance(polling_result, PollingResult):
	raise PrivacyRequestError(
	"Polling result must be PollingResult instance"
	)
	# Store results on the sub-request
	self._store_sub_request_result(polling_result, sub_request, polling_task)
	else:
	logger.info(
	f"Sub-request {sub_request.id} completed with no data (empty result)"
	)

[Linker44]

Can we add a simple test for this?

[Linker44]

good to go