Skip to content

Improve Domain Validation Error Messages#7820

Open
RobertKeyser wants to merge 5 commits intomainfrom
rkeyser/domain-validation-messages
Open

Improve Domain Validation Error Messages#7820
RobertKeyser wants to merge 5 commits intomainfrom
rkeyser/domain-validation-messages

Conversation

@RobertKeyser
Copy link
Copy Markdown
Contributor

Description Of Changes

Improve domain validation violation messages by standardizing the warn/error as: Domain validation violation (enforcement mode - <mode>): <violation message>".

Unfortunate caveat here is that this means that we'll have two error-level log lines with more or less the same contents when the enforcement is enabled. There's the initial logger.error() and then it'll get logged again when the DomainValidationError gets caught ("Connector request failed" and then the error in as structured fields). I'm alright with that, but looking for other suggestions/feedback.

Additionally, I'm adding the saas integration type to the log context for better connector observability.

Code Changes

Steps to Confirm

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

@RobertKeyser RobertKeyser requested a review from Linker44 April 2, 2026 19:47
@RobertKeyser RobertKeyser self-assigned this Apr 2, 2026
@RobertKeyser RobertKeyser requested a review from a team as a code owner April 2, 2026 19:47
@RobertKeyser RobertKeyser requested review from adamsachs and removed request for a team April 2, 2026 19:47
@vercel
Copy link
Copy Markdown
Contributor

vercel bot commented Apr 2, 2026

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

2 Skipped Deployments
Project Deployment Actions Updated (UTC)
fides-plus-nightly Ignored Ignored Preview Apr 3, 2026 3:29pm
fides-privacy-center Ignored Ignored Apr 3, 2026 3:29pm

Request Review

Copy link
Copy Markdown

@claude claude bot left a comment

Choose a reason for hiding this comment

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

Overall this is a clean, focused improvement. The two changes are logically independent and both add value.

connector_type in log context — straightforward and useful for observability. No issues.

Domain validation message improvements — the refactoring is well-motivated: separating the human-readable guidance from the exception message makes the error_details structured log field cleaner (see connection_exception_details), and the new message labels (enforcement mode - monitor / enforcement mode - enabled) are more informative than the old monitor mode. A few minor points in the inline comments:

  1. f-string vs loguru lazy evaluation — nit-level, but the previous code used loguru's preferred {} placeholder style.
  2. Double-logging — the explicit logger.error() before raise means the event will appear twice at error level. The PR description already calls this out; the inline comment offers one alternative approach if the team wants to eliminate the duplication.
  3. get_log_context() ordering — safe as written, minor note for future readers.

No blocking issues. The exception message content (violation_msg) is unchanged, so existing tests that match on "not in the list of allowed values" and "The value 'evil.com' for 'domain'" continue to pass without modification.

logger.info(
"To add support for this domain, contact Ethyca support."
)
raise DomainValidationError(violation_msg)
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

The explicit logger.error(...) on line 91 followed by raise DomainValidationError(...) here will produce two error-level log entries for the same event: the one logged explicitly, and the one logged when the upstream handler catches the exception (e.g. connection_exception_details + whatever logs it). You've flagged this in the PR description, which is appreciated.

One alternative worth considering: drop the explicit logger.error() here and instead emit the guidance lines at the catch-site, right before the upstream handler re-logs the exception. That way the violation appears once, immediately followed by the guidance. It does require touching authenticated_client.py (or wherever DomainValidationError is caught), so if keeping the change self-contained is more important than the duplicate log line, the current approach is acceptable.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

This is probably not a super common error that folks are going to hit, so I'm ok with duplicated error lines (unless a reviewer feels otherwise).

As written, it'll produce logs like this:

ERROR  Domain validation violation (enforcement mode - enabled): The value 'evil.attacker.com' for 'host' is not in the list of allowed values: [api.stripe.com, *.stripe.com].
INFO   To change domain validation behavior, set FIDES__SECURITY__DOMAIN_VALIDATION_MODE to 'monitor' or 'disabled'.
INFO   To add support for this domain, contact Ethyca support.
ERROR  Connector request failed.  [error_group=domain_blocked, error_details="The value 'evil.attacker.com' for 'host' is not in the list of allowed values: [...]", status_code=None]

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.

would this also mean duplicated error notifications on 'save' on the integration setup tab? i think it might be annoying enough

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.

what i mean is i dont mind them being repeated in the logs but two errors popping up in the ui does seem kinda bad

@codecov
Copy link
Copy Markdown

codecov bot commented Apr 2, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.02%. Comparing base (b3235db) to head (30dd22f).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff            @@
##             main    #7820    +/-   ##
========================================
  Coverage   85.01%   85.02%            
========================================
  Files         614      622     +8     
  Lines       40094    40427   +333     
  Branches     4671     4708    +37     
========================================
+ Hits        34087    34373   +286     
- Misses       4965     4998    +33     
- Partials     1042     1056    +14     

☔ 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.

@adamsachs adamsachs removed their request for review April 6, 2026 15:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants