include accounts merged - #45

• Add BFS-based accounts-merge implementation using email graph connected components.
• Provide pytest coverage for example, disjoint, chained, and duplicate-email scenarios.
• Make algorithm module importable from tests via repo-root sys.path injection.

graph TD
  T["tests/algorithms/test_accounts_merged.py"] --> F(("accountsMerge()")) --> A["adjacency list + email->name map"] --> B["BFS connected components"] --> R["merged accounts result"]
  B -->|"uses"| V["visited set"]

Loading

The following are alternative approaches to this PR:

1. Union-Find (Disjoint Set Union) instead of BFS graph traversal

• ➕ Often simpler for connectivity problems; avoids explicit BFS/queue logic
• ➕ Can be more memory-efficient by not storing a full adjacency set for each node
• ➕ Natural fit for merging via a representative/root email
• ➖ Requires careful root selection and post-processing to collect/sort groups
• ➖ Still needs mapping emails to indices/parents and gathering components at the end

Recommendation: Current BFS connected-components approach is reasonable and easy to validate with tests. If performance/memory becomes a concern for very large inputs, consider switching to DSU to avoid building dense adjacency sets.

Enhancement (1) +33 / -0

accounts_merged.pyImplement accounts merge via email graph + BFS components +33/-0

Implement accounts merge via email graph + BFS components

• Adds accountsMerge() that builds an undirected email adjacency list by connecting all emails in an account to the first email. Runs BFS over unvisited emails to collect connected components, sorts emails, and prefixes the account name via an email->name map.

Algorithms/graph/traversal/accounts_merged.py

Tests (1) +63 / -0

test_accounts_merged.pyAdd pytest coverage for accountsMerge scenarios +63/-0

Add pytest coverage for accountsMerge scenarios

• Introduces pytest cases for the canonical example, same-name disjoint accounts, chain merging through shared emails, and duplicate emails within an account. Normalizes results into sets to make comparisons order-insensitive.

tests/algorithms/test_accounts_merged.py

Description

tests/algorithms/test_accounts_merged.py imports pytest but does not use it anywhere in the file,
which adds noise and can fail builds if unused-import linting is enabled.

Code

tests/algorithms/test_accounts_merged.py[1]

+import pytest

Relevance

⭐⭐ Medium

No clear unused-import enforcement history; prior test cleanups/style suggestions often rejected.

PR-#16

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The file imports pytest at the top, but the rest of the test code uses plain assert and no
pytest APIs.

tests/algorithms/test_accounts_merged.py[1-10]
tests/algorithms/test_accounts_merged.py[11-63]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pytest` is imported but unused in `test_accounts_merged.py`.

## Issue Context
Other tests in this repo import `pytest` only when they use it (e.g., parametrization/marks/exceptions). Keeping unused imports makes test files noisier and can trip unused-import linting.

## Fix Focus Areas
- tests/algorithms/test_accounts_merged.py[1-4]

## Suggested fix
- Delete `import pytest` if not needed, or use it explicitly (e.g., for parametrization) if intended.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

accountsMerge overwrites the stored name for an email every time it is seen, so if the same email is
associated with different names, the merged component’s chosen name becomes input-order dependent
and can be incorrect. The merged label is later taken from a single email’s mapping rather than
derived/validated per connected component.

Code

Algorithms/graph/traversal/accounts_merged.py[R9-12]

+        name = account[0]
+        for dst in emails:
+            email_to_accounts[dst] = name
+            adj_lst[emails[0]].add(dst)

Relevance

⭐ Low

Team often rejects order-dependence/nondeterminism-related suggestions (traversal order, flaky tie
assertions).

PR-#41
PR-#34

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The mapping from email to name is overwritten on every encounter and then used to label whole merged
components, so conflicting names for the same email will produce unstable/incorrect merged labels
based on input order.

Algorithms/graph/traversal/accounts_merged.py[7-13]
Algorithms/graph/traversal/accounts_merged.py[31-32]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`accountsMerge` assigns `email_to_accounts[email] = name` for every occurrence of `email`, which means later accounts can overwrite earlier names for the same email. When producing the merged result, the code then labels the entire connected component using the mapping for a single email, making the output name depend on input order when conflicting names exist.

## Issue Context
This is harmless only if your input domain guarantees that all emails in a connected component share the same name (as in some problem statements). If the function is used as a general utility, it should be deterministic and/or validate that component names are consistent.

## Fix Focus Areas
- Algorithms/graph/traversal/accounts_merged.py[7-13]
- Algorithms/graph/traversal/accounts_merged.py[31-32]

## Suggested fix
- While building `email_to_accounts`, preserve the first-seen name (e.g., `email_to_accounts.setdefault(dst, name)`) OR track all names per email/component.
- When finalizing a component (after `component.sort()`), choose the label deterministically (e.g., `name = email_to_accounts[component[0]]`).
- Optionally validate consistency: ensure all `email_to_accounts[e]` in `component` match; if not, raise/return an error or pick a defined policy.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools