[rudycelekli]

Summary

POST /api/leads/dedup/merge fetched every id in duplicate_ids, merged them into the master and then deleted all of them. If master_id was also listed (for example a caller sends a whole cluster from /api/leads/dedup, whose clusters include the master), the master was deleted along with the duplicates and the response still said "merged", with duplicates_deleted counting the master. The web UI sends the merge_suggestions ids, which exclude the master, so it is not affected; API and agent callers are.

Evidence

New tests/test_lead_dedup_merge.py (runs against both the SQLite LeadDB and the ORM PgLeadStore), on current main:

FAILED test_merge_with_master_listed_as_duplicate_keeps_master[sqlite]   assert 2 == 1  (duplicates_deleted)
FAILED test_merge_with_master_listed_as_duplicate_keeps_master[orm]
FAILED test_merge_of_only_the_master_is_rejected_and_deletes_nothing[sqlite]
FAILED test_merge_of_only_the_master_is_rejected_and_deletes_nothing[orm]
4 failed

Change

The master is dropped from the duplicates, a repeated id is merged once, and a request whose only duplicate is the master gets a 400 instead of deleting it. merge_leads is untouched.

Verification

• Before: 4 failed (above). After: uv run pytest tests/test_lead_dedup_merge.py tests/test_dedup.py tests/test_lead_create_collision.py passes (22 tests).
• Not run: the full backend suite, PostgreSQL integration suite and frontend checks; only the targeted files above.

Commit is signed off per the DCO.

[debpalash]

The intended integer-ID cases are fixed, and I independently reproduced the reported 22 passing focused tests. All four GitHub checks are also green, including backend and PostgreSQL integrity/tenancy. However, the master can still be deleted through alternate representations of the same numeric ID; this is a blocking data-loss issue.

I added endpoint regression cases using duplicate master IDs represented as a leading-zero string, float, plus-prefixed string, and whitespace-padded string. All eight combinations (four inputs × SQLite LeadDB and PgLeadStore backed by SQLite) failed because the request returned 200 and the master was deleted. The two original tests do not cover repeated duplicate IDs or alternate representations; the ORM fixture tests the ORM implementation but not a real PostgreSQL database.

The correction must compare the canonical IDs returned by the store before appending to the deletion list, and deduplicate those canonical IDs. Cover aliases of both master_id and duplicate_ids, repeated IDs, master-only aliases, empty inputs, and missing duplicates. I implemented that correction and all 40 expanded focused tests pass. Because the integration cannot write to the contributor fork, #109 preserves your original commit and adds the fix and regression coverage. Please incorporate that correction before this PR is merged.

[debpalash]

[P1] Compare resolved lead identities rather than str(input). For master_id=1, duplicate_ids=["01", 2] passes this filter, but both stores in the regression fixture resolve "01" to master 1. The subsequent deletion loop deletes master 1 and returns 200. I reproduced this for "01", 1.0, "+1", and " 1 " in both fixtures (8 failures). Deduplicate and exclude the master using IDs from fetched lead records. Correction and expanded tests are published in #109.