log unknown comparator input types

[KRRT7]

PR Type

Enhancement, Bug fix

---

Description

• Capture unknown comparator types in Sentry

• Keep logging warning for unknown types

---

Diagram Walkthrough

flowchart LR
  cmp["comparator() detects unknown type"] -- "log warning" --> log["logger.warning(...)"]
  cmp -- "report to Sentry" --> sentry["sentry_sdk.capture_exception(RuntimeError(...))"]
  cmp -- "return False" --> ret["comparison fails"]

Loading

File Walkthrough

	Relevant files
Enhancement	comparator.py Report unknown comparator types to Sentry                                codeflash/verification/comparator.py Add Sentry exception capture for unknown types Preserve existing warning log message No change to return behavior (still False) +1/-0

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Logging Noise Capturing a generic RuntimeError for unknown types on every invocation may create excessive Sentry noise in hot paths; consider rate limiting, tagging, or sampling. logger.warning(f"Unknown comparator input type: {type(orig)}") sentry_sdk.capture_exception(RuntimeError(f"Unknown comparator input type: {type(orig)}")) return False # noqa: TRY300 Exception Context Using RuntimeError without attaching context (e.g., both orig/new types or sample repr) may limit debuggability; consider including both operand types and whether superset_obj is set. logger.warning(f"Unknown comparator input type: {type(orig)}") sentry_sdk.capture_exception(RuntimeError(f"Unknown comparator input type: {type(orig)}")) return False # noqa: TRY300

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
General	Avoid fake exceptions to Sentry Avoid capturing a fabricated RuntimeError; this pollutes error tracking and loses context. Use a custom message with context via capture_message at warning level, or capture the real exception when present. Also, downgrade to info/debug if this is expected noise to prevent alert fatigue. codeflash/verification/comparator.py [291-293] -logger.warning(f"Unknown comparator input type: {type(orig)}") -sentry_sdk.capture_exception(RuntimeError(f"Unknown comparator input type: {type(orig)}")) +msg = f"Unknown comparator input type: {type(orig)}" +logger.warning(msg) +sentry_sdk.capture_message(msg, level="warning") return False # noqa: TRY300 Suggestion importance[1-10]: 6 __ Why: The suggestion correctly identifies that fabricating a RuntimeError for Sentry can reduce signal quality and proposes using capture_message with the same context, which is a reasonable, non-breaking improvement. Impact is moderate since it affects observability rather than core functionality.	Low