Description
All module classes expose a fromCustomModel factory that internally calls fromModelName with modelName: 'custom'. Because modelName is the identity key used downstream (e.g. in hook deps), two consecutive custom-model loads with the same modelSource but different per-call config — for example different labelNames in PrivacyFilterModule.fromCustomModel — collapse to the same identity and do not trigger a reload. The runner keeps the old config silently.
This is not specific to PrivacyFilterModule — every peer that exposes a fromCustomModel uses the same 'custom' literal, so any fix should be applied consistently across all of them.
Possible directions:
- Derive a stable identity hash from the per-call config (
modelSource, tokenizerSource, plus module-specific fields like labelNames / viterbiBiases).
- Or accept the foot-gun and document it on every
fromCustomModel so callers know to remount/dispose explicitly.
Likelihood is low (same modelSource, different per-call config in a single session is unusual), but it's a real correctness bug — picking up wrong labels silently is worse than crashing.
Originated in #1104 (comment).
Steps to reproduce
- In a
PrivacyFilter-using component (or any peer with a fromCustomModel), load model A via fromCustomModel(modelSource, tokenizerSource, labelsA).
- Re-call
fromCustomModel(modelSource, tokenizerSource, labelsB) with the same modelSource and tokenizerSource but labelsB ≠ labelsA.
- Observe that the second load is treated as identical (identity collapses to
'custom') and the runner keeps the old labels.
Snack or a link to a repository
N/A — surfaced during PR review (#1104).
React Native Executorch version
0.9.0 (main / next)
React Native version
N/A — platform-agnostic TS logic bug.
Platforms
Platform agnostic
Acknowledgements
Yes
Description
All module classes expose a
fromCustomModelfactory that internally callsfromModelNamewithmodelName: 'custom'. BecausemodelNameis the identity key used downstream (e.g. in hook deps), two consecutive custom-model loads with the samemodelSourcebut different per-call config — for example differentlabelNamesinPrivacyFilterModule.fromCustomModel— collapse to the same identity and do not trigger a reload. The runner keeps the old config silently.This is not specific to
PrivacyFilterModule— every peer that exposes afromCustomModeluses the same'custom'literal, so any fix should be applied consistently across all of them.Possible directions:
modelSource,tokenizerSource, plus module-specific fields likelabelNames/viterbiBiases).fromCustomModelso callers know to remount/dispose explicitly.Likelihood is low (same
modelSource, different per-call config in a single session is unusual), but it's a real correctness bug — picking up wrong labels silently is worse than crashing.Originated in #1104 (comment).
Steps to reproduce
PrivacyFilter-using component (or any peer with afromCustomModel), load model A viafromCustomModel(modelSource, tokenizerSource, labelsA).fromCustomModel(modelSource, tokenizerSource, labelsB)with the samemodelSourceandtokenizerSourcebutlabelsB ≠ labelsA.'custom') and the runner keeps the old labels.Snack or a link to a repository
N/A — surfaced during PR review (#1104).
React Native Executorch version
0.9.0 (main / next)
React Native version
N/A — platform-agnostic TS logic bug.
Platforms
Platform agnostic
Acknowledgements
Yes