sickn33/agentic-awesome-skills · error · Error

Email required

Error message

Email required

What it means

Second guard in the fp-pragmatic validateUser example (skills/fp-pragmatic/SKILL.md:467). Thrown when the input passed the object check but has no string-valued email field (missing, or wrong type such as a number or null).

Source

Thrown at skills/fp-pragmatic/SKILL.md:467

// Use it
pipe(
  getManagerEmail(employee),
  O.fold(
    () => sendToDefault(),
    (email) => sendTo(email)
  )
)
```

### Validation with Multiple Checks

```typescript
// Before: Throws on first error
function validateUser(data: unknown): User {
  if (!data || typeof data !== 'object') throw new Error('Must be object')
  const obj = data as Record<string, unknown>
  if (typeof obj.email !== 'string') throw new Error('Email required')
  if (!obj.email.includes('@')) throw new Error('Invalid email')
  if (typeof obj.age !== 'number') throw new Error('Age required')
  if (obj.age < 0) throw new Error('Age must be positive')
  return obj as User
}

// After: Returns first error, type-safe
const validateUser = (data: unknown): E.Either<string, User> =>
  pipe(
    E.Do,
    E.bind('obj', () =>
      typeof data === 'object' && data !== null
        ? E.right(data as Record<string, unknown>)
        : E.left('Must be object')
    ),
    E.bind('email', ({ obj }) =>
      typeof obj.email === 'string' && obj.email.includes('@')
        ? E.right(obj.email)

View on GitHub (pinned to 58d857988f)

Solutions

  1. Declare email as required in a request schema so missing or wrong-type requests get a 400 before domain code runs
  2. Use the doc error-accumulating Either version so users see all missing fields at once
  3. Confirm field naming consistency between client and server (email vs emailAddress)

Example fix

// before
if (typeof obj.email !== 'string') throw new Error('Email required')

// after
const errors: string[] = []
if (typeof obj.email !== 'string') errors.push('Email required')
// ... collect remaining checks, then return E.left(errors) or E.right(user)
Defensive patterns

Strategy: type-guard

Validate before calling

const isRecord = (u: unknown): u is Record<string, unknown> =>
  typeof u === 'object' && u !== null
if (!isRecord(data) || typeof data.email !== 'string') {
  return badRequest('email is required and must be a string')
}

Type guard

const hasEmailString = (u: Record<string, unknown>): u is { email: string } =>
  typeof u.email === 'string'

Prevention

When it happens

Trigger: validateUser with an object that has age but no email; email set to null; email set to 123: any value where typeof obj.email is not string fails.

Common situations: Optional-field clients omitting email; forms sending empty strings (these pass the type check but fail the later @ check); API version drift where email was renamed to emailAddress; CSV imports producing numbers for digit-only emails.

Understand the failure class

Background: Schema validation failed / invalid input schema: payload rejected because its shape doesn't match the expected schema — this error's family across 28 libraries.

Related errors


AI-assisted analysis of sickn33/agentic-awesome-skills@58d857988f (2026-08-26). Data as JSON: /api/errors/3369b96e9c1c73e0. Report an issue: GitHub.