[Bug] False Company Identification

[SagiEv]

Notification

Follow-up Received: siemens
Status updated to "follow_up" based on email from LinkedIn <jobs-noreply@linkedin.com>. Subject: "Sagi, your application was sent to Jones Software"
3m ago

Email Logs

LinkedIn <jobs-noreply@linkedin.com>
7/10/2026
Sagi, your application was sent to Jones Software
siemens
follow_up
70%

THIS IS NOT SIEMENS COMPANY MAIL BUT OTHER APPLICATION

[SagiEv]

Kaltura <no-reply@kaltura.comeet-notifications.com> 7/12/2026 Application update: Full-Stack Developer at Kaltura Kaltura unknown 75%

NOT IDENTIFIED AS REJECTED AND UPDATED STATUS

[SagiEv]

Moon Active <no-reply@moonactive.comeet-notifications.com> 7/13/2026 Your application at Moon Active MoonActive unknown 75%
NOT IDENTIFIED AS REJECTED AND UPDATED STATUS

[SagiEv]

Bugfix Plan: False Company Identification

Root-Cause Analysis

After tracing the full pipeline (mail-poll-cron.js → mail-poller.service.js → email-classifier.service.js), I identified 5 distinct bugs all originating in the classifier tier (Node.js).

---

Bug 1 — LinkedIn emails always match the first-applied company (e.g. "siemens")

Symptom: Every LinkedIn jobs-noreply@linkedin.com email is matched to "siemens" regardless of subject content.

Root cause: In email-classifier.service.js:

• extractDomain("LinkedIn <jobs-noreply@linkedin.com>") → returns "linkedin" (a generic sender, not a company).
• The classifier then computes stringSimilarity.compareTwoStrings(normCompany, "linkedin") for every application. Since no application matches "linkedin" strongly, the match degrades to the companyInText fuzzy path (line 122, threshold ≥ 0.3).
• The full text blob is "linkedin <jobs-noreply@linkedin.com> sagi, your application was sent to jones software" — fuzzy-matching this entire blob against short company names like "siemens" (6 chars) produces non-zero noise ratings that accidentally cross the 0.3 threshold.
• Whichever application happens to score highest in this noise wins — and "siemens" likely has the highest incidental fuzzy overlap or was iterated first at a tied score.

The real company name ("Jones Software", "Extreme", "Cisco") is embedded in the subject line but the classifier never extracts it — it just fuzzy-matches the whole text blob.

---

Bug 2 — comeet-notifications ATS emails classified as unknown instead of rejected

Symptom: Emails from Kaltura <no-reply@kaltura.comeet-notifications.com> and Moon Active <no-reply@moonactive.comeet-notifications.com> get status unknown even though they are rejection emails.

Root cause: Two compounding issues:

1. Domain extraction fails partially: extractDomain matches @([^.]+) → extracts "kaltura" from kaltura.comeet-notifications.com. This is actually correct for company matching. But the domain "comeet-notifications" is in atsDomains list — except the regex @([^.]+) only captures the first subdomain (kaltura), not comeet-notifications. So the ATS-username extraction branch is never triggered for these emails.
2. Status detection fails: The detectStatus() function only has generic rejection keywords like "unfortunately", "not moving forward". The Comeet rejection emails likely use different phrasing (e.g., "application update", "we will not be moving forward", or the rejection signal is in the HTML body only). The bodySnippet captured from parsed.text may not contain the rejection keywords if the email is HTML-heavy.

---

Bug 3 — Application confirmation misclassified as rejected

Symptom: "Thank you for your application!" from Microsoft Careers is classified as rejected and attributed to "WEKA".

Root cause:

1. False rejection detection: detectStatus() matches on "after careful consideration" or "we have decided" type phrases. But application confirmation emails often contain phrases like "thank you", "we have received", etc. The current keyword list has no positive/neutral counterweights. A confirmation email that coincidentally contains rejection-adjacent words gets misclassified.
2. Missing confirmation-email discrimination: There's no "applied" / "confirmation" / "received your application" status category. These emails should either be ignored entirely or classified as a benign "applied" status that doesn't trigger notifications.
3. Wrong company match: extractDomain("Microsoft Careers <donotreply@email.careers.microsoft.com>") → @([^.]+) captures "email" (first subdomain). This is useless for matching. The classifier falls back to fuzzy matching the full text blob, and "WEKA" wins by noise.

---

Bug 4 — Auto-update overwrites rejected status with false positives

Symptom: An application already marked as rejected gets overwritten by a subsequent misclassified email.

Root cause: In mail-poller.service.js L182-186, the auto-update logic has no guard against downgrading terminal statuses:

if (result.applicationId && result.confidence >= AUTO_UPDATE_THRESHOLD && result.classifiedStatus !== 'unknown') {
    await applicationRepo.update(userId, result.applicationId, {
        status: result.classifiedStatus,  // blindly overwrites
    });
}

---

Bug 5 — Multiple applications to the same company are not disambiguated

Symptom: User applies to the same company for multiple roles, but emails are matched to the wrong application.

Root cause: The classifier only scores company-name similarity. When multiple applications share the same company, the role/position matching (lines 130-140) is too weak to disambiguate — score += 0.2 for exact role match vs score += 0.55 for company substring match means the first application iterated at the same company score wins.

---

Implementation Plan

Phase 1: Fix Domain Extraction (Bug 3 partial, foundation for all)

File: email-classifier.service.js

Changes to extractDomain():

Current behavior	Fixed behavior
@([^.]+) captures first subdomain only	Extract the full domain (all parts after @), then check if any segment is an ATS domain
"donotreply@email.careers.microsoft.com" → "email"	→ "microsoft" (last meaningful segment before TLD)
"no-reply@kaltura.comeet-notifications.com" → "kaltura"	→ "kaltura" (ATS detected via comeet-notifications segment, username kaltura extracted from subdomain)

Algorithm:

1. Extract full domain string after @.
2. Split by . and remove TLDs (com, net, org, co, io, ai).
3. Check if any segment matches an ATS domain → if so, extract company from subdomain prefix or username.
4. For non-ATS: check if any segment matches a known generic subdomain (email, careers, notifications, mail) and skip it. Return the most meaningful remaining segment.
5. Add a sender-display-name extraction fallback: if domain is generic (linkedin.com, gmail.com), extract the display name from the From header (e.g., "Microsoft Careers" → "Microsoft").

---

Phase 2: LinkedIn & Aggregator Subject-Line Company Extraction (Bug 1)

File: email-classifier.service.js

New function: extractCompanyFromSubject(from, subject)

Known patterns to parse:

Sender	Subject Pattern	Company to extract
jobs-noreply@linkedin.com	"…application was sent to {Company}"	{Company}
jobs-noreply@linkedin.com	"…your application to {Company}…"	{Company}
jobs-noreply@linkedin.com	"…{Company} is hiring…"	{Company}
jobalerts-noreply@linkedin.com	Various	Extract from body
messages-noreply@linkedin.com	"…from {Name} at {Company}"	{Company}

Integration into classifyEmail():

1. Detect if sender is a known aggregator (linkedin.com, indeed.com, glassdoor.com).
2. If so, call extractCompanyFromSubject() to get the real company name.
3. Use the extracted company name as the primary match signal (replaces sender-domain matching for these cases).
4. If the extracted company matches an application's company with high similarity, give it a strong score boost (≥ 0.7).

---

Phase 3: Application Confirmation Discrimination (Bug 3)

File: email-classifier.service.js

Changes to STATUS_KEYWORDS and detectStatus():

1. Add a new applied status category:

applied: [
    'application was sent', 'application has been submitted',
    'we received your application', 'thank you for applying',
    'thank you for your application', 'application received',
    'successfully submitted', 'your application to',
    'we have received your application', 'confirmation of your application'
]

2. Update STATUS_PRIORITY — applied should have the lowest priority (10) since it's informational:

applied: 10

3. Add a conflict resolution rule: if both applied and rejected keywords are detected, and the applied keywords have more hits → downgrade to applied. This prevents "Thank you for your application" from being classified as rejection.

4. Add an exclusion rule to rejected detection: if the text contains strong confirmation signals ("application was sent", "successfully submitted"), suppress the rejected classification.

---

Phase 4: Status Immutability Guard (Bug 4)

File: mail-poller.service.js

Changes to auto-update logic (line ~182):

Define terminal/immutable statuses:

const TERMINAL_STATUSES = ['rejected', 'offer', 'accepted', 'declined'];

Before auto-updating, check the current status of the matched application:

if (result.applicationId && result.confidence >= AUTO_UPDATE_THRESHOLD && result.classifiedStatus !== 'unknown') {
    // Fetch current application status
    const currentApp = applications.find(a => a.id === result.applicationId);
    
    if (currentApp && TERMINAL_STATUSES.includes(currentApp.status)) {
        // Never overwrite a terminal status — log and skip
        console.log(`[MAIL POLLER] Skipping auto-update for app ${result.applicationId}: current status "${currentApp.status}" is terminal`);
    } else {
        await applicationRepo.update(...);
        await notificationsRepo.insert(...);
    }
}

Additionally, add a status progression validation — prevent illogical transitions:

Current Status	Allowed Transitions
applied	assessment, interview, follow_up, rejected, offer
follow_up	assessment, interview, rejected, offer
assessment	interview, rejected, offer
interview	rejected, offer
offer	(terminal — no auto-update)
rejected	(terminal — no auto-update)

---

Phase 5: Multi-Application Disambiguation (Bug 5)

File: email-classifier.service.js

Changes to classifyEmail() scoring:

1. Boost role match weight when company scores are tied:

   • Current: company match 0.55 + role match 0.20 = 0.75
   • Proposed: when multiple apps match the same company, role match becomes the tiebreaker with increased weight (0.35).

2. Add role_id / Job ID matching:

   • The applications table has a role_id column. Extract job IDs from the email subject/body using regex patterns (e.g., Job ID: 12345, Req #ABC-123, Position ID: XYZ).
   • If a job ID is found and matches an application's role_id, give it a very strong signal (+0.5).

3. Subject-line role extraction for LinkedIn:

   • LinkedIn subjects like "…sent to Jones Software" don't include the role. But body text often does (e.g., "Software Engineer position").
   • Extract role from body and match against application positions.

---

Phase 6: Notification Filtering (Bug 3 secondary)

File: mail-poller.service.js

Changes:

1. Do NOT create notifications for applied status — these are just confirmations, not actionable updates.
2. Do NOT auto-update application status to applied — the user already knows they applied (they created the application entry).
3. Still log the email in email_logs for audit purposes.

const SILENT_STATUSES = ['applied', 'unknown'];

if (result.applicationId && result.confidence >= AUTO_UPDATE_THRESHOLD && !SILENT_STATUSES.includes(result.classifiedStatus)) {
    // ... existing auto-update + notification logic
}

---

File Change Summary

File	Changes	Phase
email-classifier.service.js	Rewrite extractDomain(), add extractCompanyFromSubject(), add applied status, fix scoring weights, add job ID matching	1, 2, 3, 5
mail-poller.service.js	Add terminal-status guard, status progression validation, suppress notifications for applied	4, 6

---

Execution Order

graph TD
    A["Phase 1: Fix extractDomain()"] --> B["Phase 2: LinkedIn subject extraction"]
    A --> C["Phase 3: Applied status + conflict resolution"]
    C --> D["Phase 4: Terminal status guard"]
    B --> E["Phase 5: Multi-app disambiguation"]
    D --> F["Phase 6: Notification filtering"]
    E --> F

Loading

Important

Phase 1 is the foundation — almost every bug traces back to broken domain extraction. It must be done first. Phases 2-3 can be parallelized. Phases 4-6 depend on the earlier phases.

Warning

After implementation, the existing email_logs entries with wrong matched_company values will not be retroactively fixed. Consider adding a one-time migration script or manual cleanup option if needed.

[SagiEv]

still not recognizing rejection emails:

adtran@myworkday.com
7/30/2026
Your Application for the position of Software Engineer I
Adtran
unknown
75%

draftkings@myworkday.com 7/29/2026 Update on your Software Engineer, Fullstack Application at DraftKings DraftKings unknown 75%