Recognizers listed in default_recognizers.yaml raise TypeError when enabled: constructors missing the `name` kwarg

[developer0hye]

Describe the bug

default_recognizers.yaml ships ~60 recognizers with enabled: false. That switch exists to be flipped. Three of them cannot be turned on: KrBrnRecognizer, KrDriverLicenseRecognizer and UsMbiRecognizer raise

TypeError: __init__() got an unexpected keyword argument 'name'

before the registry finishes loading.

RecognizerListLoader.get instantiates every predefined recognizer with a name keyword argument, taken from the YAML entry (or from name when class_name supplies the class — the documented rename path, see RecognizerListLoader.get_recognizer_name). A recognizer whose __init__ does not accept name therefore cannot be built from a registry configuration at all.

A fourth recognizer, KrPassportRecognizer, has the same constructor defect and is consequently absent from default_recognizers.yaml entirely — it is the only Korean recognizer missing from it, because adding an entry would have made the registry raise. It also defaults to supported_language="kr" while every other Korean recognizer defaults to ko (the ISO 639-1 code). #1742 migrated the Korean recognizers from kr to ko; #1814 added this one afterwards and reintroduced kr.

Measured across the whole shipped configuration — every entry forced to enabled: true, then loaded:

yaml entries:                  86
shipped with enabled: false:   60
load fine when enabled:        81
FAIL when enabled:              5

Of the five, two are expected: HuggingFaceNerRecognizer and BasicLangExtractRecognizer refuse to load with an actionable ImportError naming the optional dependency to install. The other three are the TypeError above, which reads as a user configuration error even though the YAML is correct.

Correction to the original report. This issue previously stated that "KrRrnRecognizer, KrBrnRecognizer, KrFrnRecognizer and KrDriverLicenseRecognizer all already accept name." That is wrong for two of them. Measured:

KrRrnRecognizer              accepts name=True
KrFrnRecognizer              accepts name=True
KrBrnRecognizer              accepts name=False
KrDriverLicenseRecognizer    accepts name=False
KrPassportRecognizer         accepts name=False
UsMbiRecognizer              accepts name=False

The scope is therefore wider than "one missing Korean recognizer", and the entries that are listed-but-unenableable matter more to users than the one that is merely unlisted.

To Reproduce

Flip any of the three to enabled: true in a registry configuration and load it:

from presidio_analyzer.recognizer_registry import RecognizerRegistryProvider

conf = {
    "global_regex_flags": 26,
    "supported_languages": ["en", "ko"],
    "recognizers": [
        {
            "name": "KrBrnRecognizer",
            "supported_languages": ["ko", "kr"],
            "type": "predefined",
            "enabled": True,
            "country_code": "kr",
        }
    ],
}
RecognizerRegistryProvider(registry_configuration=conf).create_recognizer_registry()
# TypeError: KrBrnRecognizer.__init__() got an unexpected keyword argument 'name'

For KrPassportRecognizer, add an entry to default_recognizers.yaml copied from its siblings — the same TypeError occurs. Instantiating it directly with defaults and analysing with language="ko" silently skips it, because it registered under kr.

Expected behavior

• Every recognizer listed in default_recognizers.yaml loads when enabled is true, or fails with an actionable message naming a missing optional dependency.
• KrPassportRecognizer is registered in default_recognizers.yaml (enabled: false, country_code: kr) like its siblings, and defaults to ko.

Why this was not caught

The constructor signature is part of a contract that nothing enforces, and the existing tests miss it from both sides:

• Each recognizer's own unit tests instantiate the class directly, where no name is passed. They all pass.
• The registry-level contract tests — test_predefined_pattern_recognizers_have_the_right_regex_flags, test_default_recognizers_yaml_country_code_matches_class — build the default configuration, in which those ~60 entries are disabled and therefore never constructed.

Nothing in between ever constructed them. Note the kr → ko half only affects direct instantiation: when a YAML entry omits supported_languages the loader passes the registry's language explicitly, so the class default never applies on the YAML path.

Additional context

Fixed by #2170, which adds the name argument to all four constructors, registers KrPassportRecognizer, and adds contract tests that construct every YAML entry so the next violation is caught by CI.