Updating limit of execution logs on the endpoint

[Vagoasdf]

Ticket ENG-2566

Description Of Changes

Our UI depends on the latest ExecutionLog status of each task to see the status of a task. For long lived task like polling this was causing the UI to show an incomplete status, which was confusing for end users

Code Changes

• Increasing the const of the execution log truncate

Steps to Confirm

Since the natural happening of this bug is with a long lived task such as appsflyer, we have to modify a but the base code for this

1. Set up the waiting seconds of the polling tasks at src/fides/api/service/privacy_request/request_service.py
initiate_polling_task_requeue to 60 seconds
2. Create a new Bazaarvoice polling integration (Most consistent polling access integration we have right now)
3. Create a new access request with an existing identity to bazaarvoice (IE: test@test.com )
4. Wait until the task completion
5. There should be more than 50 logs on the task
6. The task should be marked as completed correctly

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	Actions	Updated (UTC)
fides-plus-nightly	Ignored	Preview	Feb 18, 2026 4:40pm
fides-privacy-center	Ignored		Feb 18, 2026 4:40pm

[greptile-apps]

Greptile Summary

This PR increases EMBEDDED_EXECUTION_LOG_LIMIT from 50 to 1000 in the privacy request endpoints to fix a UI issue where long-running polling tasks (e.g., Bazaarvoice) would show incomplete status because the execution log truncation cut off the latest status entries.

• The fix is a single constant change in privacy_request_endpoints.py (50 → 1000) with a changelog entry
• The truncation is applied per dataset in Python (not at the SQL level), so the total response payload could grow significantly for requests touching multiple datasets
• There is a minor typo in the added comment ("Heavely" → "Heavily")
• Note: drp_endpoints.py also defines its own EMBEDDED_EXECUTION_LOG_LIMIT = 50 which appears to be unused dead code — not introduced by this PR but worth cleaning up

Confidence Score: 4/5

• This PR is safe to merge — it's a small constant change that fixes a real UI bug, with minor style concerns.
• The change is minimal (a single constant value increase) and directly addresses the reported bug. The only concerns are a typo in the comment and potential performance implications from the 20x increase in the per-dataset log limit, though these are unlikely to cause issues in practice for most deployments.
• src/fides/api/api/v1/endpoints/privacy_request_endpoints.py — minor typo and performance considerations around the limit increase

Important Files Changed

Filename	Overview
src/fides/api/api/v1/endpoints/privacy_request_endpoints.py	Increases EMBEDDED_EXECUTION_LOG_LIMIT from 50 to 1000 to fix incomplete status display for long-running polling requests. Has a typo in the comment and may have performance implications since truncation is done in Python, not SQL.
changelog/7412-update-limit-execution-logs.yaml	Standard changelog entry describing the execution log limit increase. No issues.

_{Last reviewed commit: 156da40}

[greptile-apps]

_{2 files reviewed, 2 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Typo in comment

"Heavely" should be "Heavily".

Suggested change

	# Heavely increasing the limit so the proper status of the request task is reflected
	# Heavily increasing the limit so the proper status of the request task is reflected

[greptile-apps]

Test performance impact from 20x limit increase

This limit is used in tests at test_verbose_privacy_request_embed_limit (lines ~2176 and ~3342 of the test file), which create EMBEDDED_EXECUTION_LOG_LIMIT + 10 records. With this change, those tests will now create 1,010 DB records each (up from 60), which could noticeably slow down the test suite.

Additionally, the truncation happens in Python (line 348) after fetching all logs from the DB — the query has no SQL LIMIT. This means for long-running polling requests, the endpoint could return up to 1,000 logs per dataset in a single API response. If a request touches multiple datasets, the response payload could grow substantially.

Consider whether a more targeted solution (e.g., fetching only the most recent N logs per dataset via a SQL window function, or implementing proper server-side pagination for execution logs) might address the root cause without the performance trade-off.

_{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

[galvana]

I think this is ok for now but we should probably implement some incremental loading or only showing the last 50 logs per dataset.