Lime Web Components API Documentation - v6.24.0
    Preparing search index...

    Interface Problem<T>Alpha

    Represents a problem reported by a ProblemProvider.

    Problems are system-level issues that require manual intervention, such as:

    • Failed email delivery or validation errors
    • Integration sync failures with external systems
    • Background task configuration errors
    • Data import issues with corrupt records

    Each problem belongs to a provider which owns the problem's lifecycle, storage, and available actions. Problems can optionally be linked to a specific LimeObject via the context property.

    The platform aggregates problems from all registered providers, allowing authorized users to view and manage issues across the system.

    The generic type parameter T allows providers to define strongly-typed metadata for their specific problem types.

    Basic problem with required fields only

    const problem: Problem = {
    id: 'prob-001',
    providerId: 'email-integration',
    type: 'delivery-failed',
    description: 'Email to john@example.com bounced with error: mailbox full',
    createdAt: '2024-01-15T10:30:00Z'
    };

    Problem with typed metadata

    interface EmailProblemMetadata {
    recipientEmail: string;
    bounceType: 'permanent' | 'temporary';
    smtpCode: number;
    }

    const problem: Problem<EmailProblemMetadata> = {
    id: 'email-123',
    providerId: 'email-integration',
    type: 'delivery-failed',
    description: 'Email bounced',
    createdAt: '2024-01-15T10:30:00Z',
    metadata: {
    recipientEmail: 'john@example.com',
    bounceType: 'permanent',
    smtpCode: 550
    }
    };

    Problem with error details

    const problem: Problem = {
    id: 'sync-error-042',
    providerId: 'external-crm-sync',
    type: 'connection-error',
    description: 'Failed to sync deal with external CRM',
    createdAt: '2024-01-15T14:22:00Z',
    severity: ProblemSeverity.High,
    status: 'pending-retry',
    context: { limetype: 'deal', id: 98765 },
    error: {
    message: 'ETIMEDOUT: connection timed out after 30000ms',
    code: 'ETIMEDOUT',
    stack: 'Error: ETIMEDOUT\n at TCPConnectWrap.afterConnect...'
    }
    };
    interface Problem<T = unknown> {
        context?: ProblemContext;
        createdAt: string;
        description: string;
        error?: ProblemError;
        id: string;
        metadata?: T;
        providerId: string;
        severity?: ProblemSeverity;
        status?: string;
        tags?: string[];
        type: string;
        updatedAt?: string;
        userId?: string;
    }

    Type Parameters

    • T = unknown

      The type of the metadata object. Defaults to unknown.

    Index

    Properties

    context?: ProblemContext

    Link to a related LimeObject.

    When a problem is directly related to a specific business object, the context provides navigation and filtering capabilities.

    createdAt: string

    ISO 8601 timestamp when the problem was first detected.

    createdAt: '2024-01-15T10:30:00Z'
    createdAt: new Date().toISOString()
    description: string

    Human-readable description of what went wrong.

    The description should be clear enough for users to understand the issue without needing technical knowledge. Include relevant details like affected entities, error messages, or suggested actions.

    // Good descriptions
    description: 'Email to john@example.com could not be delivered: mailbox is full'
    description: 'Failed to sync deal "Big Corp Renewal" with external system: connection timeout'

    // Avoid overly technical descriptions
    description: 'SMTP 452 4.2.2 error' // Too technical
    error?: ProblemError

    Technical error details for debugging.

    While description provides a user-friendly explanation, error captures the underlying technical details. The platform may display this in an expandable "Technical Details" section.

    id: string

    Unique identifier for the problem within the provider.

    The id only needs to be unique within a single provider. The combination of providerId and id uniquely identifies a problem across the system.

    metadata?: T

    Additional provider-specific data.

    Metadata allows providers to attach arbitrary data to problems that may be useful for debugging, displaying additional details, or powering actions. Values should be JSON-serializable.

    Use the generic type parameter to get type safety for your metadata.

    metadata: {
    originalEmailId: 'msg-123',
    recipientEmail: 'john@example.com',
    bounceType: 'permanent',
    smtpCode: 550
    }
    providerId: string

    Identifier of the ProblemProvider that reported this problem.

    This links the problem back to its owning provider, which controls the problem's lifecycle and available actions.

    This property is set automatically by the platform when problems are returned from the ProblemRepository. Providers should not include this property when returning problems from their methods.

    severity?: ProblemSeverity

    Severity level indicating the problem's urgency and impact.

    Use severity to help users prioritize which problems to address first.

    status?: string

    Current status in the problem's lifecycle.

    Status is provider-defined. Each provider can define their own status values that make sense for their workflow (e.g., 'open', 'in-progress', 'pending-retry', 'resolved').

    Status is optional. Some providers may choose to simply remove problems when they're resolved rather than tracking status transitions.

    tags?: string[]

    Tags for additional categorization and filtering.

    Tags provide flexible categorization beyond the type field. They can represent things like affected systems, error categories, or custom classifications specific to your domain.

    tags: ['email', 'bounce', 'permanent']
    tags: ['sync', 'external-system', 'timeout']
    tags: ['import', 'validation', 'required-field']
    type: string

    Type identifier for categorizing the problem.

    Types are provider-specific and allow grouping similar problems together. Use a consistent naming convention, typically with a prefix indicating the domain (e.g., 'email.delivery-failed', 'sync.connection-error').

    The provider's ProblemProvider.getType method returns display information (title, description, icon) for each type.

    // Email integration provider types
    type: 'email.delivery-failed'
    type: 'email.validation-error'
    type: 'email.attachment-too-large'

    // Sync provider types
    type: 'sync.connection-error'
    type: 'sync.data-conflict'
    type: 'sync.rate-limited'
    updatedAt?: string

    ISO 8601 timestamp when the problem was last modified.

    Updated when status changes, metadata is modified, or any other property is updated after initial creation.

    userId?: string

    Identifier of the user associated with this problem.

    This could be the user who triggered the action that failed, or the user responsible for the affected data. The exact meaning depends on the provider's context.