#2222·presidio

HuggingFaceNerRecognizer cannot be enabled from its shipped default_recognizers.yaml entry (no model_name, constructor raises)

Author: juno-junhoCreated Aug 5, 2026Updated Aug 11, 2026

Describe the bug

HuggingFaceNerRecognizer ships in default_recognizers.yaml (enabled: false), but the entry cannot actually be turned on. It carries no model_name, and the constructor calls load(), which raises before the registry finishes building. So the switch exists, but flipping it always crashes: the entry is not usable as shipped.

To Reproduce

python
# flip HuggingFaceNerRecognizer to enabled: true in default_recognizers.yaml, then:
from presidio_analyzer.recognizer_registry import RecognizerRegistryProvider
RecognizerRegistryProvider(conf_file="default_recognizers.yaml").create_recognizer_registry()
# ValueError: model_name must be set before calling load(). Pass it to __init__() or set it directly.

(Requires the transformers extra to be installed; found while running an enable-everything sweep during the #2216 benchmark work.)

Expected behavior

One of: the shipped entry includes a working default model_name, or the recognizer defers load() so the registry can build and the error surfaces at analyze time with a pointer to the missing config, or the shipped entry documents inline that model_name is required to enable it. Any of these would be an improvement over an unconditional crash during registry construction.

Additional context

Found independently from two directions: my enable-everything sweep, and the constructor-coverage work in #2170, where it's currently recorded in a NOT_LOADABLE_FROM_SHIPPED_ENTRY exclusion with a guard test so the coverage gap stays visible. This issue is the tracking item for actually fixing the entry. Related: #2176, #2217.

Source: data-privacy-stack/presidio