jackwener/OpenCLI · error · CommandExecutionError

Jike notifications API returned a notification without a typ

Error message

Jike notifications API returned a notification without a type

What it means

CommandExecutionError thrown by mapNotification when a notification object from the Jike notifications API has a valid id but its type field is missing, empty, or not a string. The type drives resolveActionLabel (mapping TYPE_LABELS and fallback heuristics), so a notification without a type cannot be labeled and the library refuses to emit a row rather than outputting an empty type.

Source

Thrown at clis/jike/notifications.js:53

    if (sourceType.includes('LIKE')) return '赞了你';
    if (sourceType.includes('COMMENT')) return '评论了你';
    if (sourceType.includes('FOLLOW')) return '关注了你';
    if (sourceType.includes('REPOST')) return '转发了你';
    if (sourceType.includes('MENTION')) return '提到了你';
    if (sourceType.includes('REPLY')) return '回复了你';
    return notification.type;
}

function cleanContent(value) {
    return typeof value === 'string' ? value.replace(/\n/g, ' ').slice(0, 100) : '';
}

function mapNotification(notification) {
    if (!notification || typeof notification !== 'object' || typeof notification.id !== 'string' || !notification.id) {
        throw new CommandExecutionError('Jike notifications API returned a malformed notification');
    }
    if (typeof notification.type !== 'string' || !notification.type) {
        throw new CommandExecutionError('Jike notifications API returned a notification without a type');
    }
    const actionItem = notification.actionItem;
    if (!actionItem || typeof actionItem !== 'object' || Array.isArray(actionItem)) {
        throw new CommandExecutionError('Jike notifications API returned a malformed action item');
    }
    if (!Array.isArray(actionItem.users)) {
        throw new CommandExecutionError('Jike notifications API returned a malformed users list');
    }
    const names = actionItem.users.map((user) => {
        if (!user || typeof user !== 'object') {
            throw new CommandExecutionError('Jike notifications API returned a malformed user');
        }
        return typeof user.screenName === 'string' ? user.screenName : '';
    }).filter(Boolean);
    const referenceItem = notification.referenceItem;
    const referenceContent = referenceItem && typeof referenceItem === 'object' && !Array.isArray(referenceItem)
        ? referenceItem.content
        : '';

View on GitHub (pinned to 49907e53dc)

Solutions

Capture the raw API item to confirm which new notification shape lacks type
Retry — check whether only certain notification categories (e.g. new Jike features) trigger it and filter them out client-side
Update mapNotification/TYPE_LABELS in clis/jike/notifications.js to handle the new type or default it (e.g. `notification.type || 'UNKNOWN'`)
Pin/restore an older API behavior by requesting the notifications page via the standard web client to compare payload shapes
Report the new type upstream so TYPE_LABELS gains a mapping

Example fix

// before
if (typeof notification.type !== 'string' || !notification.type) {
  throw new CommandExecutionError('Jike notifications API returned a notification without a type');
}
// after: tolerate unknown types
const type = typeof notification.type === 'string' && notification.type ? notification.type : 'UNKNOWN';
// and pass `type` through to resolveActionLabel

Defensive patterns

Strategy: type-guard

Validate before calling

function hasNotificationType(n) {
  return typeof n?.type === 'string' && n.type.length > 0;
}
const usable = body.data.filter(n => hasNotificationId(n) && hasNotificationType(n));

Type guard

function hasNotificationType(n) {
  return typeof n === 'object' && n !== null && typeof n.type === 'string' && n.type !== '';
}

Try / catch

try {
  rows = await jikeNotifications(page, limit);
} catch (e) {
  if (/without a type$/.test(e.message)) {
    // new/unknown notification category: refetch and map unknown types to a label
    rows = (await fetchRaw()).map(n => ({ ...n, type: n.type || 'UNKNOWN' })).filter(r => r.type !== 'UNKNOWN' || true);
  } else throw e;
}

Prevention

Normalize missing types to a sentinel like 'UNKNOWN' in your own mapping layer
Keep TYPE_LABELS up to date when Jike ships new notification categories
Log unknown types instead of hard-failing so the CLI degrades gracefully
Test the mapper against captured real payload samples including edge categories

When it happens

Trigger: Calling the jike notifications command when /1.0/notifications/list returns items whose type field is absent or empty string — typically a new or deprecated notification category the CLI has not seen.

Common situations: Jike introduces a new notification kind served without the legacy type field; deprecated notification types removed from payloads; A/B-tested API responses omitting type; parsing the wrong endpoint version.

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 jackwener/OpenCLI@49907e53dc (2026-08-29). Data as JSON: /api/errors/cb72d96d788e3bc2. Report an issue: GitHub.