transformers - ✅(Solved) Fix TypeError in rope validation: set -= list when config loaded from JSON [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
huggingface/transformers#45068Fetched 2026-04-08 01:40:49
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
1
Author
Participants
Timeline (top)
referenced ×4closed ×1cross-referenced ×1

Error Message

TypeError: unsupported operand type(s) for -=: 'set' and 'list'

Root Cause

Model configs like Qwen3.5 define ignore_keys_at_rope_validation = {"mrope_section", "mrope_interleaved"} as a Python set. However, JSON has no set type — when the config is serialized to JSON and loaded back (e.g. via huggingface_hub dataclass validation), sets become lists. The _check_received_keys method doesn't account for this.

Fix Action

Fix

# src/transformers/modeling_rope_utils.py, line 919
- received_keys -= ignore_keys
+ received_keys -= set(ignore_keys)

set() is a no-op when input is already a set, and correctly handles the list case.

PR fix notes

PR #45069: Fix TypeError in rope validation when ignore_keys is a list

Description (problem / solution / changelog)

What does this PR do?

Fixes a TypeError in _check_received_keys (line 919 of modeling_rope_utils.py) where received_keys -= ignore_keys fails when ignore_keys is a list instead of a set.

Root cause

Model configs (Qwen3.5, ErnieVLMoe, GLM4V, Ministral3) define ignore_keys_at_rope_validation as a Python set. JSON has no set type, so when configs are serialized/deserialized (e.g. via huggingface_hub strict dataclass validation), sets become lists. The -= operator on set doesn't accept list operands.

Fix

- received_keys -= ignore_keys
+ received_keys -= set(ignore_keys)

set() is a no-op for set inputs and correctly converts lists.

Error

huggingface_hub.errors.StrictDataclassClassValidationError: 
  Class validation error for validator 'validate_rope':
    TypeError: unsupported operand type(s) for -=: 'set' and 'list'

Triggered by vLLM 0.18.0 serving Qwen/Qwen3.5-35B-A3B.

Fixes #45068

Changed files

  • src/transformers/modeling_rope_utils.py (modified, +1/-1)

Code Example

TypeError: unsupported operand type(s) for -=: 'set' and 'list'

---

# transformers==5.4.0, huggingface_hub>=1.7
from transformers import AutoConfig
# Works fine (loads from Python class):
config = AutoConfig.from_pretrained("Qwen/Qwen3.5-35B-A3B")

# Fails when loaded via huggingface_hub strict dataclass validation
# (e.g. through vLLM which triggers this path):
# StrictDataclassClassValidationError: Class validation error for validator 'validate_rope':
#     TypeError: unsupported operand type(s) for -=: 'set' and 'list'

---

# src/transformers/modeling_rope_utils.py, line 919
- received_keys -= ignore_keys
+ received_keys -= set(ignore_keys)
RAW_BUFFERClick to expand / collapse

Bug description

_check_received_keys in modeling_rope_utils.py (line 919) performs received_keys -= ignore_keys where received_keys is a set but ignore_keys can be a list after JSON deserialization, causing:

TypeError: unsupported operand type(s) for -=: 'set' and 'list'

Root cause

Model configs like Qwen3.5 define ignore_keys_at_rope_validation = {"mrope_section", "mrope_interleaved"} as a Python set. However, JSON has no set type — when the config is serialized to JSON and loaded back (e.g. via huggingface_hub dataclass validation), sets become lists. The _check_received_keys method doesn't account for this.

Reproduction

# transformers==5.4.0, huggingface_hub>=1.7
from transformers import AutoConfig
# Works fine (loads from Python class):
config = AutoConfig.from_pretrained("Qwen/Qwen3.5-35B-A3B")

# Fails when loaded via huggingface_hub strict dataclass validation
# (e.g. through vLLM which triggers this path):
# StrictDataclassClassValidationError: Class validation error for validator 'validate_rope':
#     TypeError: unsupported operand type(s) for -=: 'set' and 'list'

Triggered by vLLM 0.18.0 serving Qwen/Qwen3.5-35B-A3B.

Affected models

Any model defining ignore_keys_at_rope_validation: Qwen3.5, ErnieVLMoe, GLM4V, Ministral3, etc.

Fix

# src/transformers/modeling_rope_utils.py, line 919
- received_keys -= ignore_keys
+ received_keys -= set(ignore_keys)

set() is a no-op when input is already a set, and correctly handles the list case.

Environment

  • transformers 5.4.0
  • huggingface_hub 1.7.2 / 1.8.0
  • vLLM 0.18.0
  • Python 3.13

extent analysis

Fix Plan

To fix the issue, we need to modify the _check_received_keys method in modeling_rope_utils.py to handle the case where ignore_keys is a list.

  • Modify the line received_keys -= ignore_keys to received_keys -= set(ignore_keys) to ensure that the subtraction operation is performed between two sets.

Example code:

# src/transformers/modeling_rope_utils.py, line 919
received_keys -= set(ignore_keys)

This change will correctly handle both cases where ignore_keys is a set or a list.

Verification

To verify that the fix worked, you can test the _check_received_keys method with both a set and a list as input for ignore_keys. The method should now correctly perform the subtraction operation without raising a TypeError.

Example test code:

# Test with set
ignore_keys = {"mrope_section", "mrope_interleaved"}
received_keys = {"mrope_section", "mrope_interleaved", "other_key"}
received_keys -= set(ignore_keys)
print(received_keys)  # Should print: {'other_key'}

# Test with list
ignore_keys = ["mrope_section", "mrope_interleaved"]
received_keys = {"mrope_section", "mrope_interleaved", "other_key"}
received_keys -= set(ignore_keys)
print(received_keys)  # Should print: {'other_key'}

Extra Tips

  • Make sure to update the transformers library to the latest version to ensure that the fix is included.
  • If you are using a custom implementation of the _check_received_keys method, make sure to apply the same fix to your custom implementation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING