Describe the bug
The frontend converter picker advertises TokenBijectionConverter, but the GUI/API construction path cannot provide its required keyword-only tokenizer. The UI exposes only the optional seed parameter, so every preview attempt returns HTTP 500 and the converter cannot complete its primary GUI workflow.
TokenBijectionConverter.__init__ requires a tokenizer with get_vocab(), while the converter catalog exposes only string-coercible parameters. The required tokenizer is therefore omitted from the catalog response before the frontend renders the form:
Recommended direction: exclude or clearly disable this converter in the GUI for now rather than silently selecting a fixed tokenizer. The converter is documented as using the target model's tokenizer vocabulary, and the GUI supports heterogeneous targets without a serializable tokenizer configuration. A hard-coded tokenizer could therefore be incorrect or misleading for the active target and may also introduce an implicit model download.
A durable GUI implementation should make tokenizer choice explicit and backend-managed, for example through a supported tokenizer identifier/catalog with validation and a clear relationship to the active target. Until that exists, the catalog/UI should generically identify converters with required non-GUI-constructible parameters and avoid offering an action that can only fail.
Steps/Code to Reproduce
- Activate any writable text target.
- Open Chat and enter a prompt.
- Open the converter panel and select
TokenBijectionConverter.
- Expand Parameters; observe that only
seed is available.
- Choose Preview.
Equivalent API behavior:
POST /api/converters
{"type":"TokenBijectionConverter","params":{}}
HTTP 500
Failed to create converter: TokenBijectionConverter.__init__() missing 1 required keyword-only argument: 'tokenizer'
Expected Results
The GUI should never present an impossible converter workflow. Until supported tokenizer selection exists, TokenBijectionConverter should be excluded or shown as unavailable with an actionable explanation, and Preview should not issue a request that can only fail.
If GUI tokenizer support is added, the user should select a supported backend-managed tokenizer identifier, incompatible or unavailable choices should fail validation before creation, and a valid selection should preview successfully without an implicit arbitrary default.
Actual Results
The converter appears selectable and looks ready to use, but Preview makes two failed create attempts and reports:
Failed to create converter: TokenBijectionConverter.__init__() missing 1 required keyword-only argument: 'tokenizer'
Digit and Letter Bijection converters preview and apply successfully in the same workflow, isolating the failure to Token Bijection construction.
Screenshots
N/A. The exact visible error and API response are included above.
Versions
- OS: Windows_NT
- Browser: Playwright Chromium (
@playwright/test 1.62.1)
- Python: 3.14.4
- PyRIT:
1.1.0.dev0, main at e9277c45ab136b39f9aca12745bb45746f7d9963
- Python package versions: repository
uv.lock at the tested commit
Describe the bug
The frontend converter picker advertises
TokenBijectionConverter, but the GUI/API construction path cannot provide its required keyword-onlytokenizer. The UI exposes only the optionalseedparameter, so every preview attempt returns HTTP 500 and the converter cannot complete its primary GUI workflow.TokenBijectionConverter.__init__requires a tokenizer withget_vocab(), while the converter catalog exposes only string-coercible parameters. The required tokenizer is therefore omitted from the catalog response before the frontend renders the form:converter_service.pycatalog projectionconverter_service.pyinstance creationTokenBijectionConverterconstructorRecommended direction: exclude or clearly disable this converter in the GUI for now rather than silently selecting a fixed tokenizer. The converter is documented as using the target model's tokenizer vocabulary, and the GUI supports heterogeneous targets without a serializable tokenizer configuration. A hard-coded tokenizer could therefore be incorrect or misleading for the active target and may also introduce an implicit model download.
A durable GUI implementation should make tokenizer choice explicit and backend-managed, for example through a supported tokenizer identifier/catalog with validation and a clear relationship to the active target. Until that exists, the catalog/UI should generically identify converters with required non-GUI-constructible parameters and avoid offering an action that can only fail.
Steps/Code to Reproduce
TokenBijectionConverter.seedis available.Equivalent API behavior:
Expected Results
The GUI should never present an impossible converter workflow. Until supported tokenizer selection exists,
TokenBijectionConvertershould be excluded or shown as unavailable with an actionable explanation, and Preview should not issue a request that can only fail.If GUI tokenizer support is added, the user should select a supported backend-managed tokenizer identifier, incompatible or unavailable choices should fail validation before creation, and a valid selection should preview successfully without an implicit arbitrary default.
Actual Results
The converter appears selectable and looks ready to use, but Preview makes two failed create attempts and reports:
Digit and Letter Bijection converters preview and apply successfully in the same workflow, isolating the failure to Token Bijection construction.
Screenshots
N/A. The exact visible error and API response are included above.
Versions
@playwright/test1.62.1)1.1.0.dev0,mainate9277c45ab136b39f9aca12745bb45746f7d9963uv.lockat the tested commit