findAndMergeMembersWithSameVerifiedEmailsInDifferentPlatforms is registered in workflows.ts but nothing ever triggers it — script_executor_worker/src/main.ts registers only the four cleanup schedules, and services/cronjobs holds only archived_repositories. Duplicate members therefore accumulate until someone starts a sweep by hand.
Impact (reported downstream at linuxfoundation/insights#2093): on the LFX Insights leaderboard for apache/logging-log4j2, one person renders as two contributors — ramanathan1504 (57 authored commits) and ramanathanbscmca@gmail.com (10). The split is confined to the git platform; github attributes cleanly. The identity link was already confirmed under SUPPORT-42182.
The detection query is not at fault. A git-created member receives its email as a verified type: 'username' identity (commit_service.py), and the query in member.repo.ts constrains only a.type = 'email', leaving b.type free — so that identity satisfies the b side. Reproduced locally against the real identity shapes: the pair matches when the GitHub member has the email as a verified identity, and does not when that identity is unverified or absent. Pairs like this one are already detectable; the sweep simply never runs.
Fix: register a recurring schedule for the workflow alongside the existing ones in schedules/. No matching semantics change — both sides still require verified identities, so this adds no new trust in self-asserted commit emails. PR to follow.
findAndMergeMembersWithSameVerifiedEmailsInDifferentPlatformsis registered inworkflows.tsbut nothing ever triggers it —script_executor_worker/src/main.tsregisters only the four cleanup schedules, andservices/cronjobsholds onlyarchived_repositories. Duplicate members therefore accumulate until someone starts a sweep by hand.Impact (reported downstream at linuxfoundation/insights#2093): on the LFX Insights leaderboard for
apache/logging-log4j2, one person renders as two contributors —ramanathan1504(57 authored commits) andramanathanbscmca@gmail.com(10). The split is confined to thegitplatform;githubattributes cleanly. The identity link was already confirmed under SUPPORT-42182.The detection query is not at fault. A git-created member receives its email as a verified
type: 'username'identity (commit_service.py), and the query inmember.repo.tsconstrains onlya.type = 'email', leavingb.typefree — so that identity satisfies thebside. Reproduced locally against the real identity shapes: the pair matches when the GitHub member has the email as a verified identity, and does not when that identity is unverified or absent. Pairs like this one are already detectable; the sweep simply never runs.Fix: register a recurring schedule for the workflow alongside the existing ones in
schedules/. No matching semantics change — both sides still require verified identities, so this adds no new trust in self-asserted commit emails. PR to follow.