-
Type:
Bug
-
Resolution: Unresolved
-
None
-
Affects Version/s: None
-
Component/s: API, LanguageResources, translate5 AI
-
Medium
-
None
-
None
-
Emptyshow more show less
Problem
Language resources store resource specific settings in the field "specificData" (a JSON text). For OpenAI based resources this contains the model and the model properties (for example batch size or reasoning effort). For other resources translate5 stores its own internal data there, for example the list of memories of a t5memory resource.
The REST API offers two ways to change this data, and they behave differently:
- The model properties endpoint (/editor/plugins_openai_modelprops/ID) changes single properties, keeps all others and corrects values that are out of range.
- The general language resource endpoint (/editor/languageresourceinstance/ID) accepts "specificData" on creation (POST) and on change (PUT) as free text and stores it as sent.
The second way causes these problems:
- "specificData" is not checked to be valid JSON. If an API user sends invalid JSON (for example with single quotes), it is stored. Afterwards the list of language resources can no longer be loaded for any user, because reading the invalid value fails.
- A PUT with "specificData" replaces the whole content. All model properties set before are lost. For other resource types, internal data that translate5 needs (for example the t5memory memory list) can be removed or changed by mistake.
In addition, a smaller problem was found while documenting the model properties endpoint:
- If a PUT request sends a JSON body that contains the parameter "data" as JSON object (instead of a JSON string), the server answers with an internal server error (500) instead of processing the request or returning a clear error message. This is part of the general request handling, so it can happen for all REST endpoints.
Solution
specificData via the languageresourceinstance endpoint. The developer decides between two options:
- Option A, unify: handle "specificData" in POST and PUT the same way as the model properties endpoint does. Validate that it is valid JSON and reject invalid JSON with a clear error (422). On PUT, merge the sent keys into the existing data instead of replacing it. Protect keys that translate5 manages itself (for example the t5memory memory list) from being changed via the API.
- Option B, disable: stop accepting "specificData" in POST and PUT. Changes are then only possible through the dedicated endpoints (for OpenAI: the model properties endpoint, which can also set the model). Check first, which resource types need "specificData" on creation via the API (OpenAI resources currently need it to set the model), and provide another way for these cases.
- In both options: reading the language resource list must not fail completely because one language resource contains invalid "specificData". Log the problem with the language resource id and show the resource without its specific data.
- Update the API documentation (pages "LanguageResources: Instance" and "LanguageResources: OpenAI model properties") to the chosen behaviour.
JSON body with a "data" object. In the general request handling, accept "data" as a JSON object as well as a JSON string, or answer with a clear error (400 or 422) instead of an internal server error.