Skip to content

fix: let the shipped HuggingFaceNerRecognizer entry be enabled (#2222) - #2228

Open
overgoy wants to merge 1 commit into
data-privacy-stack:mainfrom
overgoy:fix-huggingface-shipped-entry
Open

fix: let the shipped HuggingFaceNerRecognizer entry be enabled (#2222)#2228
overgoy wants to merge 1 commit into
data-privacy-stack:mainfrom
overgoy:fix-huggingface-shipped-entry

Conversation

@overgoy

@overgoy overgoy commented Aug 9, 2026

Copy link
Copy Markdown

Enabling the shipped HuggingFaceNerRecognizer entry in default_recognizers.yaml crashes the whole registry build, because the entry carries no model_name and EntityRecognizer.__init__ calls load(). The switch exists but can never be turned on.

load() now leaves the recognizer inactive and logs why, so the registry builds. analyze() raises with the same actionable message, so a recognizer without a model is reported rather than quietly returning no entities, which for a PII library would read as "this text is clean".

The guard in analyze() is on model_name rather than on a missing pipeline, so lazy loading through load() behaves exactly as before.

HuggingFaceNerRecognizer can therefore leave NOT_LOADABLE_FROM_SHIPPED_ENTRY, where the contract test kept it with a comment calling it a pre-existing defect in the entry. The set stays in place, and empty, so the next entry that cannot load as shipped is visible there instead of silently untested.

Fixes #2222.

Verified locally: the reproduction from the issue now builds a registry containing the recognizer, and using it without a model still explains why. Full analyzer suite passes (3316 passed, 13 skipped); ruff check is clean. ruff format reports one pre-existing complaint in tests/test_recognizers_loader_utils.py that is unrelated to these lines, so I left it alone rather than reformatting untouched code.

Disclosure: this was prepared with an AI coding assistant. The project's full analyzer test suite and linter were run locally before opening this.

…privacy-stack#2222)

default_recognizers.yaml ships HuggingFaceNerRecognizer with enabled: false
and no model_name. EntityRecognizer.__init__ calls load(), and load() raised
when model_name was missing, so flipping the shipped entry to true aborted the
construction of the whole registry rather than adding one recognizer. The
switch existed but could never be turned on.

load() now leaves the recognizer inactive and logs why, so the registry builds.
analyze() raises with the same actionable message, so a recognizer without a
model is still reported rather than quietly returning no entities, which for a
PII library would read as "this text is clean".

The guard in analyze() is on model_name rather than on a missing pipeline, so
lazy loading through load() keeps working as before.

HuggingFaceNerRecognizer therefore leaves NOT_LOADABLE_FROM_SHIPPED_ENTRY,
which the contract test kept it in with a comment calling it a pre-existing
defect in the entry. The set stays in place, and empty, so the next entry that
cannot load as shipped is visible there instead of silently untested.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

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

1 participant