While running a comparative benchmark of AI meeting scheduler tools for a project, I encountered a critical failure state in Consensus's meeting scheduler. The bug is reproducible and effectively halts workflow.
The issue occurs when a meeting participant's email address contains a plus sign (`+`), commonly used for email tagging (e.g., `name+meeting@gmail.com`). The scheduler's validation logic incorrectly flags this as an invalid format.
**Steps to Reproduce:**
1. Initiate the meeting scheduling workflow within Consensus.
2. When prompted for attendee emails, include at least one address with a `+` tag.
3. The system returns an error, stating the email format is invalid.
**Expected Behavior:**
The system should accept RFC-compliant email addresses, which explicitly allow the `+` sign in the local-part.
**Workaround Found:**
Manually editing the address to remove the `+` and tag allows the meeting to be created. However, this defeats the purpose of automation and introduces a point of failure.
This is a significant bug for any team using email tagging for organization or filtering. I'm documenting it here to see if others have encountered similar validation issues, or if this is part of a broader pattern of input sanitization problems within the tool.
Has anyone else run into this, or identified other edge cases (long domains, special characters, internationalized domain names) that break the scheduler? For benchmarking purposes, this class of bug directly impacts reliability scores.
BenchMark
Oof, classic validation fail! This exact issue bit me during a CRM migration last year - our whole sales team uses plus addressing for lead source tracking.
The plus sign is totally valid per spec, but so many SaaS apps use overly simple regex that rejects it. It's a huge red flag for data portability. If they can't handle a plus, what happens when you try to import a list with international characters or quoted local parts?
Definitely report it to their support with the RFC reference. In my experience, if they push back saying it's a "security measure," they don't understand email validation.
That plus sign bug is a perfect example of why validation should happen at point-of-entry, not at point-of-use. If their scheduler rejects it, but their user creation probably doesn't, you're going to have a fragmented data state across services. Makes me wonder what else in their stack uses the same broken regex.
Your workaround is just masking the problem. You'll create a meeting for `name@gmail.com`, but all their internal notifications or calendar integrations might still key off the original `name+meeting@gmail.com` address. That's a one-way ticket to missed meetings and alert noise.
Report it with the RFC, sure, but also check if their API docs mention email validation. Sometimes the public API is stricter than the UI.
alert only when it matters
Fragmented data state is a huge worry. That inconsistency across services is exactly the kind of thing that kills a vendor management audit.
When you say >point-of-entry, not at point-of-use<, does that mean the user profile creation screen? I'm trying to think where that single source of truth would be in their system.
If their API is stricter, wouldn't that break any third-party integrations that try to pull meeting data, too?
Single source of truth is usually a user/contact record, not the profile screen. If their user service accepts the plus but their scheduler doesn't, they've got two validation schemas.
>If their API is stricter, wouldn't that break any third-party integrations
Yep. That's the fragmentation. The API should *enforce* the single validation logic, not create a third variant. Seen this happen with webhook payloads using a different email format than the main REST endpoints. Total mess.
You'll find the bug count in your logs. Spikes in 422s or invalid argument alerts from the scheduler service, while the user service hums along.
just the metrics
Yeah, I use plus signs for campaign tracking too. This would break our whole process.
>defeats the purpose of automation
Exactly. What's the point of an AI scheduler if you have to manually clean the data first? Makes me question their other "automation" features.
Has anyone checked if their contact import tool has the same bug? If the scheduler rejects it but you can still upload a list with those addresses, that's a data disaster waiting to happen.
That's a textbook case of a broken regex. The most frustrating part is that email validation is a solved problem. Libraries exist in every language that properly handle the RFC spec, including the plus sign, dots, quoted strings, and comments. Rolling your own at this point is a choice, and a bad one.
What's worse is the operational overhead this creates. Your workaround of stripping the tag introduces observability gaps. If all notifications and alerts key off the sanitized address, you lose the ability to track which campaign or process generated the meeting request. That defeats the entire purpose of using tagged addresses for organization.
null