Other Classes

Success payload for MoEngageInitializeSDKTask.

Echoes which configuration source produced the initialised SDK — .code when the caller passed a MoEngageSDKConfig programmatically, .file when the SDK loaded the configuration from Info.plist (the initializeDefaultInstance(...) overloads).

Typed task returned by MoEngage init overloads (e.g. MoEngage.initializeDefaultLiveInstance(_:)). onSuccess fires once the SDK instance is created and all public APIs are safe to call.

onFailure fires when the supplied MoEngageSDKConfig (or the Info.plist fallback) fails to parse. The reason is a MoEngageCoreRequestFailureReason carrying moduleCode == .invalidInitialisationConfiguration; downcast to read it: (failure.reason as? MoEngageCoreRequestFailureReason)?.moduleCode.

Fire-and-forget call sites keep working unchanged via @discardableResult.

Success payload for MoEngageSDKAnalytics.trackEvent(...). onSuccess fires when the event has been validated and accepted into the local batch storage; acceptedProperties / droppedPropertyKeys surface the per-key validation outcome.

Success payload for the setUserAttribute* family (including setAlias, setUniqueID, setEmailID, setName, setLocation, etc. — all of which internally normalise to a setUserAttribute call).

Echoes the validated attribute accepted into local batch storage.

Success payload for MoEngageSDKAnalytics.identifyUser(...).

Echoes the identities recorded locally.

Success payload for MoEngageSDKAnalytics.setDeviceAttribute(...).

Success payload for MoEngageSDKAnalytics.appStatus(...).

Success payload for the six enable/disable compliance toggles (enableDataTracking, disableDataTracking, enableIDFATracking, disableIDFATracking, enableIDFVTracking, disableIDFVTracking). All six share MoEngageTrackingToggleTask; kind + enabled together identify which toggle fired and which direction.

Success payload for MoEngageSDKAnalytics.trackLocale(...).

trackLocale resolves onSuccess when at least one sub-attribute was accepted. If every attempted sub-attribute was skipped (e.g. data tracking is disabled, user is opted out, call from extension context), the task rejects with MoEngageCoreRequestFailureReason(moduleCode: .trackLocaleSubAttributeFailed) instead — per-attribute reasons appear in the failure message.

Shape mirrors Android’s UserAttributeResult.Bulk for cross-platform parity.

Success payload for MoEngageSDKAnalytics.processURL(...).

Success payload for MoEngageSDKAnalytics.flush(...). Empty marker — onSuccess firing on a MoEngageFlushTask indicates the batch sync was server-acknowledged. No further metadata is surfaced today; future revisions may add e.g. batch count / batch ID.

Success payload for MoEngageSDKAnalytics.resetUser(...). Empty marker — onSuccess firing on a MoEngageResetUserTask indicates the user state has been reset (session + attributes invalidated, new UID issued).

Success payload for MoEngageSDKAnalytics.getUserIdentities(...). Carries the current identity map for the requested workspace.

Typed task returned by MoEngageSDKAnalytics.trackEvent(...). Carries the MoEngageTrackEventResult payload on success.

Typed task returned by every setUserAttribute* family method — base setUserAttribute, epoch/date/ISO variants, setAlias, setUniqueID, setEmailID, setName, setFirstName, setLastName, setMobileNumber, setGender, setDateOfBirth*, trackUserPushPreference, setLocation. Carries the MoEngageUserAttributeResult payload on success.

Typed task returned by MoEngageSDKAnalytics.identifyUser(...) (both overloads). Carries the MoEngageIdentifyUserResult payload on success.

Typed task returned by MoEngageSDKAnalytics.setDeviceAttribute(...). Carries the MoEngageSetDeviceAttributeResult payload on success.

Typed task returned by MoEngageSDKAnalytics.appStatus(...). Carries the MoEngageAppStatusResult payload on success.

Typed task returned by all six enable/disable compliance toggles (enableDataTracking / disableDataTracking / enableIDFATracking / disableIDFATracking / enableIDFVTracking / disableIDFVTracking). The shared task type carries a MoEngageTrackingToggleResult whose kind + enabled fields identify which toggle fired.

Typed task returned by MoEngageSDKAnalytics.trackLocale(...). Carries the MoEngageTrackDeviceLocaleResult payload on success.

Typed task returned by MoEngageSDKAnalytics.processURL(...). Carries the MoEngageProcessURLResult payload on success.

Typed task returned by MoEngageSDKAnalytics.flush(...) (the typed-task sibling of the deprecated completion-block variant). Carries a MoEngageFlushResult on success once the batch sync has been server-acknowledged.

Typed task returned by MoEngageSDKAnalytics.resetUser(...) (the typed-task sibling of the deprecated completion-block variant). Carries a MoEngageResetUserResult on success once the user state has been reset.

Typed task returned by MoEngageSDKAnalytics.getUserIdentities(...) (the typed-task sibling of the deprecated completion-block variant). Carries a MoEngageGetUserIdentitiesResult with the current identity map on success.

Model class to enable console logging and logLevel

/ Model class to support environmet configuration

MoEngage SDK Project specific Configuration

Class to configure Recommendations.

Success payload for MoEngageCoreIntegrator.enableSDKForPartner(...). Echoes the partner integration type that was enabled.

Success payload for MoEngageCoreIntegrator.addIntergrationInfo(...). Echoes the integration info that was recorded in the workspace’s core cache.

Typed task returned by MoEngageCoreIntegrator.enableSDKForPartner(...). Carries a MoEngagePartnerEnablementResult on success.

Typed task returned by MoEngageCoreIntegrator.addIntergrationInfo(...). Carries an MoEngageIntegrationInfoResult on success.

MoEngageSDKAppPersonalization provides APIs to track personalization experience events such as impressions and clicks.

Base class for SDK-autonomous events. Customers dispatch via if let sync = event as? MoEngageSDKEventSyncSuccess { ... }; unknown future subtypes are forward-compatible. The originating workspace is carried by accountMeta on the observer callback, not duplicated on the event.

A background batch sync completed successfully (server-acknowledged). Confirms that locally-batched events reached MoEngage; per-call onSuccess only confirms local-batch acceptance.

A background batch sync failed. Carries the failure and whether the SDK plans to retry; permanently-dropped batches arrive with willRetry == false.

JWT authentication details containing token and user identifier

This class encapsulates JWT authentication information required for MoEngage SDK authentication. It contains the JWT token and associated user identifier.

Usage Example

let jwtDetails = MoEngageJwtAuthenticationDetails(
    token: "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
    identifier: "user123"
)

MoEngageSDKCore.sharedInstance.passAuthenticationDetails(jwtDetails)

JWT Token Requirements

• The token should be a valid JWT (JSON Web Token)
• It should be signed with a supported algorithm
• The token should contain the required claims for MoEngage authentication
• The token should not be expired

Thread Safety

This class is immutable after initialization and is thread-safe.

Objective-C Compatibility

This class is fully compatible with Objective-C through the @objc annotation.

JWT Authentication Error class that inherits from the base authentication error.

This class represents JWT-specific authentication errors that occur during network requests in the MoEngage SDK. It provides JWT-specific error codes and payload information.

Usage Example

class MyJwtListener: MoEngageAuthenticationError.Listener {
    func onError(_ error: MoEngageAuthenticationError) {
        if let jwtError = error as? MoEngageJwtAuthenticationError {
            // Handle JWT-specific error
            switch jwtError.details.code {
            case .timeConstraintFailure:
                // Handle token expiration - refresh token
                refreshJwtToken()
            case .invalidSignature:
                // Handle signature validation failure - re-authenticate
                reAuthenticate()
            case .tokenNotAvailable:
                // Handle missing token - provide new token
                provideJwtToken()
            default:
                // Handle other errors
                logError(jwtError)
            }
        }
    }
}

Base class for authentication details used in MoEngage SDK

This abstract base class provides a common interface for all authentication detail types in the MoEngage SDK. Concrete implementations should override the asInternalDetails() method to provide the appropriate internal representation.

Usage

Do not instantiate this class directly. Instead, use concrete implementations like MoEngageJwtAuthenticationDetails for specific authentication methods.

Base Authentication Error class that encapsulates detailed error information.

This class represents authentication errors that occur during network requests in the MoEngage SDK. It provides comprehensive error details including specific error codes, human-readable messages, and account metadata for debugging and error handling purposes.

Error Handling

Authentication errors can occur due to various reasons such as token expiration, invalid signatures, malformed tokens, or network issues. This class provides structured error information to help developers handle these scenarios appropriately.

Failure reason for MoEngageCore init / bootstrap failures. moduleCode is non-nil for module-specific failures; nil when a shared base-class Code is used.

Failure delivered to MoEngageTaskProtocol.onFailure and thrown from MoEngageTaskProtocol.result(). Wraps a MoEngageRequestFailureReason, a human-readable message, and an optional underlying cause. NSError subclass for ObjC bridging.

Supports NSSecureCoding. On decode, the reason is reconstructed as the base MoEngageRequestFailureReason carrying the shared code — module-specific subclass metadata is dropped. When decoding chained failures, include both NSError.self and MoEngageRequestFailure.self in the unarchiver’s allow-list.

Reason describing why a public API call failed.

The base class carries the shared SDK-wide failure code (network, parse, auth, etc.) that any module can emit. Module-specific failures are represented by subclasses (MoEngageCoreRequestFailureReason, MoEngageInAppRequestFailureReason, MoEngageMessagingRequestFailureReason) which carry their own ModuleCode enum plus module-specific metadata (e.g. campaignId).

Customers downcast error.reason as? MoEngageInAppRequestFailureReason to access module-specific information, or switch reason.code for cross-cutting handling. open so first-party SDK pods can declare module-specific reason subclasses (MoEngageCoreRequestFailureReason in MoEngageCore, MoEngageInAppRequestFailureReason in MoEngageInApps, MoEngageMessagingRequestFailureReason in MoEngageMessaging, etc.). The shared Code enum on this base class covers cross-cutting failure modes; each subclass adds a nested ModuleCode enum for module-specific codes.

Base class for the per-API typed tasks returned by public SDK APIs.

Exposes an ObjC-bridgeable Any-typed onSuccess / onFailure surface; Swift consumers get the typed equivalents through MoEngageTaskProtocol on each subclass.

• Handlers are single-slot (last-writer-wins) and always dispatched on the main thread.
• Late-attach replays the cached outcome immediately when a handler is attached after resolve / reject has already fired.
• cancel() clears pending handlers; the underlying SDK operation continues to natural completion and its result is discarded.

A utility class for handling accessibility data in push notifications. This class provides methods to fetch and assess accessibility information from push payloads, ensuring that the content displayed adheres to accessibility settings on the device.

Module-specific failure reason for MoEngageMessaging failures emitted from the typed-task API surface.

Customers inspect moduleCode first for a Messaging-specific signal; if nil, fall back to the base class’s code for shared cross-cutting handling (e.g. .sdkNotInitialized when no instance is registered for the given appId).

Success payload for MoEngagePushTokenTask — fires when the push-token signal (setPushToken / didFailToRegisterForPush / registerFor* / setUserNotificationCategories) has been accepted by the SDK and the downstream APNs registration pipeline has been kicked off.

Marker — no echo needed. Customers identify which method was tracked from the call they initiated. APNs-side success/failure (token delivery, permission grant) continues to arrive via the MoEngageMessagingDelegate, not via this task.

Important: onSuccess confirms that the SDK has accepted the customer’s call into its pipeline. It does NOT indicate that APNs delivered the device token, that the user granted notification authorization, or that a push was actually delivered — those outcomes are surfaced separately through MoEngageMessagingDelegate.

Success payload for MoEngagePassPushPayloadTask — fires when the push payload (process(notificationPayload:forInstanceID:) / didReceieveNotification(...)) has been validated and dispatched to the SDK’s push-processing pipeline.

Success payload for MoEngageLogNotificationTask. Resolves onSuccess after the impression is accepted into the local batch storage. Returns onFailure(.duplicateImpression) if the same impression payload was already tracked in a prior call — applies to logNotificationReceived(withPayload:) only; the logNotificationClicked variants do not dedup.

Customers identify which event was tracked from the method they called — no kind discriminator on the Result.

Carries the full notification payload that was tracked. Nested aps / moengage dictionaries and primitive values pass through unchanged; only the top-level AnyHashable keys are normalised to String (push-payload keys are String in practice — non-string keys fall back to String(describing:)).

Success payload for MoEngageNavigationTask — fires when the navigation action (navigateToPushSettings()) has been issued to the OS. Does NOT confirm that Settings actually opened on screen; UIApplication.open(_:) completes asynchronously and the SDK doesn’t observe the final outcome.

Marker — customer asked to navigate to settings; success means the SDK successfully issued the open request.

Typed task returned by the push-token / registration family on MoEngageSDKMessaging — setPushToken(_:), didFailToRegisterForPush(), registerForRemoteNotification(...), registerForRemoteProvisionalNotification(...), setUserNotificationCategories(_:). Resolves with MoEngagePushTokenResult (marker) once the signal is accepted into the SDK’s APNs-registration pipeline.

Failure codes:

• .invalidPushToken — nil/empty token (setPushToken only)
• .sdkNotInitialized (shared) — no SDK instance / message-delegate handler unavailable

.pushRegisterFailed is reserved for future use; not currently emitted. didFailToRegisterForPush() resolves — the task tracks the customer’s CALL, not the APNs event being reported.

APNs-side outcomes (token delivery, permission grant) arrive via MoEngageMessagingDelegate, unchanged.

Typed task returned by the push-payload-processing methods on MoEngageSDKMessaging — process(notificationPayload:forInstanceID:). Carries a MoEngagePassPushPayloadResult on success once the payload has been validated and dispatched to the SDK’s push-processing pipeline.

onFailure fires with MoEngageMessagingRequestFailureReason.code == .invalidParameters (shared) when the payload fails validation, or .sdkNotInitialized when no SDK instance is registered.

Typed task returned by the notification-impression-logging methods on MoEngageSDKMessaging — logNotificationReceived(withPayload:) / logNotificationClicked(withPayload:) / logNotificationClicked(withResponse:). Carries a MoEngageNotificationTrackingResult on success after the impression is accepted into the local batch storage. For logNotificationReceived(withPayload:) only, returns onFailure(.duplicateImpression) when the same impression payload was already tracked in a prior call.

Customers identify which event was tracked from the method they called — there is no kind discriminator on the Result.

Typed task returned by MoEngageSDKMessaging.navigateToPushSettings(). Carries a MoEngageNavigationResult marker on success once the navigation request has been issued to the OS. Does NOT confirm that the Settings app actually opened — UIApplication.open(_:) completes asynchronously.

MoEngage Cards Accessibility data

A model representing the card data for a MoEngage campaign.

JavaScript bridge constants for InApp messaging Provides constants for JavaScript bridge communication.

Production date provider using system Date()

Uses the system’s current date and time for all operations. This is the default implementation used in production code.

Core Frequency Capping evaluator that determines whether campaigns can be shown

This class implements the main FC evaluation logic, checking various FC rules including global settings, campaign-level overrides, and tag-based rules.

Key Features

• Global FC Evaluation: Checks global FC limits for all trigger types
• Campaign-Level Override: Handles campaign-specific FC settings
• Tag-Based Evaluation: Supports both all-tags (AND) and any-tag (OR) conditions
• Bypass Logic: Handles ignore_global_fc and ignore_fc_count flags
• Pure Function: No side effects, logging handled by controller integration

FC Evaluation Flow

1. Check if campaign has FC bypass flags (ignore_global_fc > ignore_fc_count > normal)
2. Evaluate global FC limits for the trigger type
3. Evaluate campaign-level FC limits
4. Evaluate tag-based FC limits (if applicable)
5. Return evaluation result with blocking reason

Bypass Precedence

• ignore_global_fc: Skip all global and tag checks, return success
• ignore_fc_count: Continue evaluation but skip increment
• normal: Full FC evaluation with all rules

:nodoc

A custom content view that forwards specific properties to the parent container. This is used inside a UIScrollView to properly handle dataSource and other properties.

Video widget view for inapps.

Video widget helpers.

Manages In-App campaign assets: downloading images/HTML resources, resolving local file paths, and removing expired or campaign-specific assets. Exposed to Objective-C via the generated MoEngageInApps-Swift.h (no separate .h).

Manages in-app campaign data including saving, parsing, filtering, and categorization. State management, utilities, campaign removal, and logging methods are in MoEngageInAppDataManager+State.swift.

Module-specific failure reason for MoEngageInApps failures emitted from the typed-task API surface.

Customers inspect moduleCode first for an InApp-specific signal; if nil, fall back to the base class’s code for shared cross-cutting handling (e.g. .sdkNotInitialized when no instance is registered for the given appId).

Success payload for MoEngageShowInAppTask (intrusive in-apps: pop-up / fullscreen).

Resolves AFTER the campaign is visibly rendered on screen — i.e. after the MoEngageInAppNativeDelegate.inAppShown(...) delegate callback path has fired. try await result() blocks until visual attach + delay-manager + render completion. For animated campaigns this can be several seconds after the showInApp(...) call returns.

Customers can use either signal — the typed task resolves at the same anchor as the inAppShown delegate. The delegate hook continues to work unchanged for customers who prefer the legacy convention; new customers can await task.result() and inspect the typed payload directly.

Success payload for MoEngageShowNudgeTask (non-intrusive nudges anchored to a screen position). Same resolution timing semantics as MoEngageShowInAppResult — fires after visible render via the MoEngageInAppNativeDelegate.inAppShown(...) delegate callback path.

Success payload for MoEngageSelfHandledTrackingTask — fires after the shown / clicked / dismissed impression has been accepted into the SDK’s tracking pipeline. Customers identify which event was tracked from the method they called (selfHandledShown / Clicked / Dismissed), not from the Result.

Success payload for MoEngageGetSelfHandledInAppTask — fires once the single-eligible-campaign fetch completes. campaign is nil when no eligible self-handled campaign exists for the workspace at this time (a valid customer-observable state — not a failure).

Success payload for MoEngageGetSelfHandledInAppsTask — fires once the all-eligible-campaigns fetch completes. campaigns may be empty (a valid customer-observable state — not a failure).

Typed task returned by MoEngageSDKInApp.showInApp(...) overloads (intrusive in-apps: pop-up / fullscreen). Carries a MoEngageShowInAppResult on success AFTER the campaign is visibly rendered on screen — resolve fires from the MoEngageInAppNativeDelegate.inAppShown(...) delegate-path, NOT from the createInApp completion boundary. See MoEngageShowInAppResult for the full resolve-point semantic.

onFailure fires with MoEngageInAppRequestFailureReason whose moduleCode is one of:

• .campaignNotFound — no eligible campaign for this request (covers no-campaigns-available, no-campaign-after-eligibility, blocked-in-VC, display-cancelled-by-override, AND preemption by a higher-priority campaign). campaignId is nil.
• .renderFailed — selected native campaign’s payload couldn’t be fetched OR the view-builder / on-screen-attach step failed for a campaign that had already been selected. campaignId carries the failed campaign’s identifier.
• .htmlAssetLoadFailed — selected HTML campaign’s assets couldn’t be loaded. campaignId carries the failed campaign’s identifier. Or .sdkNotInitialized (shared code) when no SDK instance is registered for the supplied appId.

Multiple pre-sync calls: earlier calls reject with .duplicateFunctionCall; the most-recent retained task settles on the actual outcome at sync-completion.

Typed task returned by MoEngageSDKInApp.showNudge(...) overloads (non-intrusive nudges anchored to a screen position). Carries a MoEngageShowNudgeResult on success AFTER the nudge is visibly rendered on screen — same resolve semantic as MoEngageShowInAppTask.

onFailure codes are the same set as MoEngageShowInAppTask — .campaignNotFound, .renderFailed, .htmlAssetLoadFailed, or .sdkNotInitialized.

Multiple pre-sync calls at the SAME position: earlier calls reject with .duplicateFunctionCall; the most-recent retained task at that position settles on the actual outcome at sync-completion. Different positions are independent (slot-keyed by position).

Typed task returned by the three self-handled impression tracking methods on MoEngageSDKInApp — selfHandledShown(campaignInfo:), selfHandledClicked(campaignInfo:), selfHandledDismissed(campaignInfo:) (and their forAppId: overloads). Carries a MoEngageSelfHandledTrackingResult on success once the impression has been accepted into the SDK’s tracking pipeline.

The Result echoes campaignName + campaignId. Customers identify which event was tracked from the method they called — there is no kind discriminator on the Result.

Typed task returned by MoEngageSDKInApp.getSelfHandledInApp(...) (the typed-task sibling of the deprecated completion-block variant). Carries a MoEngageGetSelfHandledInAppResult on success — campaign is non-nil if an eligible self-handled campaign was found, or nil if none is available (the absence of an eligible campaign is a valid customer-observable state, not a failure).

Typed task returned by MoEngageSDKInApp.getSelfHandledInApps(...) (the typed-task sibling of the deprecated completion-block variant). Carries a MoEngageGetSelfHandledInAppsResult on success — campaigns may be empty.

A model class representing a frequency capping rule for in-app campaigns.

This class defines the parameters for frequency capping rules, including maximum display count, time unit, and period for the rule.

Key Features:

• Maximum display count configuration
• Time unit specification (session, hour, day)
• Period duration for the rule
• Validation and error handling

Frequency capping rule for in-app campaigns. Base class for tag-based and global rules.

A comprehensive data container class that manages all in-app campaign data and state.

This class serves as the central repository for in-app campaign information, including different types of campaigns (general, triggered, self-handled, non-intrusive), campaign states, timing controls, and synchronization settings. It conforms to NSCoding and MoEngageDataModel protocols for data persistence and management.

A class that manages delivery control settings for in-app campaigns.

This class handles various aspects of campaign delivery including priority levels, persistence settings, and frequency capping metadata. It conforms to NSCoding and Codable protocols for data persistence and serialization.

A class that manages display settings and rules for in-app messages.

This class handles the visual presentation and timing of in-app campaigns, including display rules, delays, and formatting. It conforms to NSCoding and Codable protocols for data persistence and serialization.

A class that defines display rules and conditions for in-app messages.

This class manages when and where in-app messages should be displayed based on screen contexts and screen names. It helps control the targeting and placement of in-app campaigns to ensure they appear at the right time and location. It conforms to NSCoding and Codable protocols for data persistence.

A class that manages frequency capping metadata for in-app campaigns.

This class controls how often in-app messages can be displayed to users, including maximum display counts, minimum delays between displays, and whether to ignore global delay settings. It conforms to NSCoding and Codable protocols for data persistence and serialization.

A class that tracks the state and interaction history of an in-app campaign.

This class maintains important information about how an in-app campaign has been displayed and interacted with, including display counts, timing information, and completion status. It helps manage campaign lifecycle and prevents over-display of campaigns. It conforms to MoEngageModelObject, NSCoding, and Codable protocols for data persistence and management.

Model describing the navigation action for inapp

InApp Display Rules

MoEngageInAppSelfHandledData provides info about multiple selfhandled Inapps

This class can be used for all inapp instance agnostic behaviour

Typed task returned by MoEngageSDKRecommendations.fetchRecommendations(...).

Resolves with MoEngageRecommendedItems — either from the local cache when a valid entry exists for the request, or from the server. An empty items array resolves as a success; “no recommendations right now” is a valid answer rather than a fault.

onFailure fires with MoEngageRecommendationsRequestFailureReason whose moduleCode is one of .invalidRequest, .payloadTooLarge, .rateLimitExceeded, .internalServerError or .unknownError. Failures raised before the module is reached carry a nil moduleCode and a shared code instead — .sdkNotInitialized when no SDK instance is registered for the supplied workspace id, .featureDisabled when the SDK is disabled or Recommendations is blocked by remote config, and .networkError / .parseError for transport and decoding failures.

Handlers are single-slot and always dispatched on the main thread. Attaching onSuccess / onFailure and awaiting result() on the same task drops the closures — use one surface per task.

Public entry point for the Recommendations module.

A thin dispatch adapter — all guard/cache/network logic lives in MoEngageRecommendations/fetch(recommendationId:itemId:includedFields:task:forInstance:). This type’s only job is to get onto the correct MoEngageSDKInstance actor safely and hand off.

Success payload for MoEngageFetchRecommendationsTask.

Carries the recommended products for the requested recommendation, ranked best-first. An empty items array is a success, not a failure — it means no recommendations are currently available for this user, which the app is expected to branch on rather than treat as an error.

Each element is one product’s catalog attributes. The keys and their value types are defined by the catalog on the MoEngage dashboard and are passed through verbatim — hence snake_case keys such as product_id and image_link, and values that may be strings, numbers or booleans rather than only strings. product_id, title, image_link and link are always returned; anything else depends on the requested includedFields.

Module-specific failure reason for MoEngageRecommendations failures emitted from the typed-task API surface.

Customers inspect moduleCode first for a Recommendations-specific signal; if nil, fall back to the base class’s code for shared cross-cutting handling (e.g. .sdkNotInitialized when this module’s own SDK-enabled check fails, or .featureDisabled when the module is blocked via remote config).

One case this subclass can never carry: .sdkNotInitialized raised by MoEngageAction itself when no instance is registered for the workspace id at all — that auto-rejection happens before this module’s code ever runs, so it always produces the shared MoEngageCoreRequestFailureReason, never this type.