yuliskov/SmartTube · error · IllegalStateException

Wrong message view type. Please, report this issue on GitHub

Error message

Wrong message view type. Please, report this issue on GitHub with full stacktrace in description.

What it means

getViewHolder maps the int viewType RecyclerView hands it to a holder config: built-ins are handled by the switch, custom types by scanning customContentTypes with Math.abs matching (sign still encodes direction). The IllegalStateException fires only when the viewType matches nothing — the library itself labels this a should-never-happen branch and asks for a GitHub report. In practice it means the holders instance creating holders disagrees with the view types actually in flight.

Source

Thrown at chatkit/src/main/java/com/stfalcon/chatkit/messages/MessageHolders.java:571

            case VIEW_TYPE_TEXT_MESSAGE:
                return getHolder(parent, incomingTextConfig, messagesListStyle);
            case -VIEW_TYPE_TEXT_MESSAGE:
                return getHolder(parent, outcomingTextConfig, messagesListStyle);
            case VIEW_TYPE_IMAGE_MESSAGE:
                return getHolder(parent, incomingImageConfig, messagesListStyle);
            case -VIEW_TYPE_IMAGE_MESSAGE:
                return getHolder(parent, outcomingImageConfig, messagesListStyle);
            default:
                for (ContentTypeConfig typeConfig : customContentTypes) {
                    if (Math.abs(typeConfig.type) == Math.abs(viewType)) {
                        if (viewType > 0)
                            return getHolder(parent, typeConfig.incomingConfig, messagesListStyle);
                        else
                            return getHolder(parent, typeConfig.outcomingConfig, messagesListStyle);
                    }
                }
        }
        throw new IllegalStateException("Wrong message view type. Please, report this issue on GitHub with full stacktrace in description.");
    }

    @SuppressWarnings("unchecked")
    protected void bind(final ViewHolder holder, final Object item, boolean isSelected,
                        final ImageLoader imageLoader,
                        final View.OnClickListener onMessageClickListener,
                        final View.OnLongClickListener onMessageLongClickListener,
                        final View.OnFocusChangeListener onMessageFocusChangeListener,
                        final DateFormatter.Formatter dateHeadersFormatter,
                        final SparseArray<MessagesListAdapter.OnMessageViewClickListener> clickListenersArray) {

        if (item instanceof IMessage) {
            ((MessageHolders.BaseMessageViewHolder) holder).isSelected = isSelected;
            ((MessageHolders.BaseMessageViewHolder) holder).imageLoader = imageLoader;
            holder.itemView.setOnLongClickListener(onMessageLongClickListener);
            holder.itemView.setOnClickListener(onMessageClickListener);
            holder.itemView.setOnFocusChangeListener(onMessageFocusChangeListener);

View on GitHub (pinned to 3de8d90593)

Solutions

Build every MessagesListAdapter with the exact MessageHolders instance on which the custom types were registered, and never swap to an adapter with different types on the same list
When you must change adapter shape on an existing MessagesList, use a fresh list or clear the RecycledViewPool first
If neither applies, capture the full stacktrace and report it on the stfalcon chatkit GitHub tracker as the message requests

Example fix

// before
list.setAdapter(new MessagesListAdapter<>(senderId, new MessageHolders())); // custom types were registered on a different holders instance

// after
MessageHolders holders = new MessageHolders().registerContentType((byte) 1, ...);
list.setAdapter(new MessagesListAdapter<>(senderId, holders));

Defensive patterns

Strategy: validation

Validate before calling

// Before swapping adapters with different holder shapes on the same list:
messagesList.getRecycledViewPool().clear();
messagesList.setAdapter(new MessagesListAdapter<>(senderId, sameHoldersInstance));

Prevention

Construct every MessagesListAdapter with the same MessageHolders instance that registered your content types
Do not reuse one MessagesList for adapters with different custom types without clearing the recycled view pool
Make ContentChecker return true only for types actually registered on that holders instance

When it happens

Trigger: RecyclerView requesting a viewType produced by a different MessageHolders configuration, e.g. an adapter constructed with holders that never registered the custom type now being bound; swapping adapters with different holder configs on a MessagesList whose recycled views carry stale view types; a ContentChecker returning true for a type that was not registered on this MessageHolders instance.

Common situations: Creating a new MessagesListAdapter with default holders while reusing the same MessagesList for custom content-type messages; a shared adapter across screens with per-screen holder configs; version upgrades where view-type numbering changed.

Related errors

AI-assisted analysis of yuliskov/SmartTube@3de8d90593 (2026-08-22). Data as JSON: /api/errors/37b892304c2d791d. Report an issue: GitHub.