we-promise/sure · info

<%= class_name %>Account::ActivitiesProcessor - Unmapped act

Error message

<%= class_name %>Account::ActivitiesProcessor - Unmapped activity type '#{normalized_type}' for account #{@<%= file_name %>_account.id}. Consider adding to ACTIVITY_TYPE_TO_LABEL mapping.

What it means

In the generated ActivitiesProcessor, label_from_type upcases the provider's activity type and looks it up in the ACTIVITY_TYPE_TO_LABEL constant. When the normalized type is present but has no entry, it logs this warning (recommending a mapping addition) and returns "Other" as the label. This is cosmetic: activity import, amounts, and symbol rendering are unaffected — only the human-readable label falls back.

Source

Thrown at lib/generators/provider/family/templates/activities_processor.rb.tt:221

        amount
      end
    end

    def build_description(activity_type, symbol)
      type_label = label_from_type(activity_type)
      if symbol.present?
        "#{type_label} - #{symbol}"
      else
        type_label
      end
    end

    def label_from_type(activity_type)
      normalized_type = activity_type&.upcase
      label = ACTIVITY_TYPE_TO_LABEL[normalized_type]

      if label.nil? && normalized_type.present?
        Rails.logger.warn(
          "<%= class_name %>Account::ActivitiesProcessor - Unmapped activity type '#{normalized_type}' " \
          "for account #{@<%= file_name %>_account.id}. Consider adding to ACTIVITY_TYPE_TO_LABEL mapping."
        )
      end

      label || "Other"
    end
end

View on GitHub (pinned to e69894adb9)

Solutions

1. Take the exact normalized_type from the warning and add it to ACTIVITY_TYPE_TO_LABEL in the generated app/models/<provider>/activities_processor.rb with a sensible label
2. Mirror the addition in lib/generators/provider/family/templates/activities_processor.rb.tt so regenerating the provider keeps the mapping
3. If the type is noise for your users, map it to "Other" explicitly to silence the warning
4. After the next sync, verify the activities list shows the new label

Example fix

# generated activities_processor.rb - before
ACTIVITY_TYPE_TO_LABEL = {
  "BUY" => "Buy", "SELL" => "Sell", "DIVIDEND" => "Dividend"
}.freeze

# after
ACTIVITY_TYPE_TO_LABEL = {
  "BUY" => "Buy", "SELL" => "Sell", "DIVIDEND" => "Dividend",
  "REINVEST_DIVIDEND" => "Dividend Reinvestment", "STOCK_SPLIT" => "Stock Split"
}.freeze

# Normalize provider types against the mapping during import; flag unmapped ones
def known_activity_type?(raw)
  ACTIVITY_TYPE_TO_LABEL.key?(raw.to_s.upcase)
end

unmapped = activities.reject { |a| known_activity_type?(a[:type]) }
Rails.logger.info("Unmapped types incoming: #{unmapped.map { |a| a[:type] }.uniq.inspect}") if unmapped.any?

def known_activity_type?(raw)
  ACTIVITY_TYPE_TO_LABEL.key?(raw.to_s.upcase)
end

When it happens

Trigger: Provider returns an activity type string that is not a key of ACTIVITY_TYPE_TO_LABEL after upcasing — e.g. a newly introduced type like "REINVEST_DIVIDEND" or "STOCK_SPLIT" when the generated constant only covers common types (BUY/SELL/DIVIDEND/...). Casing differences do NOT trigger it because the lookup is upcased first.

Common situations: The provider API adds a new activity type after the integration was generated; the generator's default mapping was never customized to the provider's real taxonomy; multi-word or prefixed codes (e.g. "TRANSFER_OUT") missing from the constant.

Related errors

• Invalid currency code '#{currency_value}' for <%= class_name
• Invalid institution URL for <%= class_name %> account #{prov
• Invalid currency code '#{currency_value}' for <%= class_name
• Unexpected response format from search endpoint
• Could not determine currency for #{symbol} from Tiingo searc

AI-assisted analysis of we-promise/sure@e69894adb9 (2026-08-21). Data as JSON: /api/errors/8bf6d4c078ae5674. Report an issue: GitHub.