Skip to content

notify: per-username result counts (fixes #2990) - #3071

Open
SkxOverKill wants to merge 1 commit into
sherlock-project:masterfrom
SkxOverKill:fix/notify-per-scan-result-count
Open

SkxOverKill wants to merge 1 commit into
sherlock-project:masterfrom
SkxOverKill:fix/notify-per-scan-result-count

Conversation

@SkxOverKill

Copy link
Copy Markdown

Summary

Fixes #2990 — the "Search completed with X results" line showed a cumulative total across all usernames (and relied on a fragile countResults() - 1 off-by-one compensation).

Root cause

sherlock_project/notify.py used a module-level globvar that is never reset. A single QueryNotifyPrint instance is created once in main() (sherlock.py:812) and shared across every username scan, so the counter accumulated across scans.

Changes

  • sherlock_project/notify.py
    • Remove the module-level globvar.
    • Track the count on the instance (self._result_count, initialised in __init__).
    • finish() reads self._result_count directly (no extra increment + - 1) and resets it so the next username scan starts from zero.
  • sherlock_project/sherlock.py
    • Call query_notify.finish() inside the per-username loop so each scan prints its own "Search completed with X results" line.
  • tests/test_notify.py — new offline unit tests covering per-instance counts and reset between scans.

Verification

  • Reproduced before: two scans (2 claimed, then 1 claimed) printed 2 results then 4 results. After the fix: 2 results then 1 results.
  • pytest tests/test_notify.py passes (2 passed).
  • Full offline suite remains green (the only pre-existing failures are environment-related py -m subprocess tests that also fail on master).

@SkxOverKill
SkxOverKill requested a review from ppfeister as a code owner August 12, 2026 08:06
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.

fix: result counter accumulates across usernames due to module-level global

1 participant