Skip to content

Conversation

@Mihir-Mavalankar
Copy link
Contributor

@Mihir-Mavalankar Mihir-Mavalankar commented Nov 13, 2025

PR Details

  • Reworking my approach to updating this function for triage-signals. I am removing the cache based check (added this a few days ago PR) and going to add an if else in this function for the new behaviour.
  • I am putting stuff that is going to be common for both approaches in functions so that it can be re-used.

@Mihir-Mavalankar Mihir-Mavalankar self-assigned this Nov 13, 2025
@Mihir-Mavalankar Mihir-Mavalankar requested a review from a team as a code owner November 13, 2025 23:25
@github-actions github-actions bot added the Scope: Backend Automatically applied to PRs that change backend components label Nov 13, 2025
# cache.add uses Redis SETNX which atomically sets the key only if it doesn't exist
# Returns False if another process already set the key, ensuring only one process proceeds
if not cache.add(cache_key, True, timeout=600): # 10 minute
if seer_automation_rate_limit_check(group) is False:
Copy link
Contributor

Choose a reason for hiding this comment

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

Bug: Concurrency Race: Duplicate Tasks From Missing Atomicity

Removing the atomic cache.add() deduplication check introduces a race condition where multiple concurrent processes can all pass the lock.locked() check and trigger duplicate start_seer_automation.delay() tasks for the same group. The lock check only reads the lock state without acquiring it, so multiple processes can simultaneously see the lock as unlocked and proceed. The previous cache.add() with Redis SETNX provided atomic protection against this.

Fix in Cursor Fix in Web

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The fixability check guards against this.

Copy link
Member

Choose a reason for hiding this comment

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

does it? fixability takes some time to generate so there is a window in which multiple tasks could start

Copy link
Contributor Author

Choose a reason for hiding this comment

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

  • True but in that time the issue summary lock is in effect preventing multiple runs. Issue summary lock + fixability if statement are enough.
  • Also by removing this lock we are going to the behaviour from 3 days ago.

@roaga
Copy link
Member

roaga commented Nov 13, 2025

Is this PR just re-organizing code without touching functionality?

I would also move all helpers out of the main post process file and into a seer utils file, e.g. seer/autofix/utils.py

@Mihir-Mavalankar
Copy link
Contributor Author

Mihir-Mavalankar commented Nov 13, 2025

Is this PR just re-organizing code without touching functionality?

I would also move all helpers out of the main post process file and into a seer utils file, e.g. seer/autofix/utils.py

Yes, just re-organizing apart from the cache check. Cache check is being removed, though that was added by me 3 days ago. It's not essential.
I can move it to the utils file.

@roaga
Copy link
Member

roaga commented Nov 14, 2025

why remove the cache check @Mihir-Mavalankar ? see #103345 (comment)

@codecov
Copy link

codecov bot commented Nov 14, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

Additional details and impacted files
@@             Coverage Diff             @@
##           master   #103345      +/-   ##
===========================================
+ Coverage   71.28%    80.67%   +9.38%     
===========================================
  Files        9231      9235       +4     
  Lines      394276    394495     +219     
  Branches    25149     25149              
===========================================
+ Hits       281051    318248   +37197     
+ Misses     112777     75799   -36978     
  Partials      448       448              

return True


def seer_automation_rate_limit_check(group) -> bool:
Copy link
Member

Choose a reason for hiding this comment

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

can't we just use is_seer_scanner_rate_limited directly? what's the point of this wrapper?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Removed it.

return is_rate_limited


def seer_automation_permission_and_type_check(group) -> bool:
Copy link
Member

Choose a reason for hiding this comment

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

can we add a type annotation to the param?

can we also rename the function something like "is_issue_eligible_for_seer_automation" or something else more readable than the current name

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Scope: Backend Automatically applied to PRs that change backend components

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants