PUT method (addressing_mode=0) expects extra_data be populated as if it was addressing_mode=2 #29

New issue

Closed

opened 2025-04-30 23:20:16 +00:00 by stanislav.hejny · 1 comment

stanislav.hejny commented

2025-04-30 23:20:16 +00:00

Member

Ref epic: CleverSwarm Onboarding #58

while testing update function of CleverSwarm integration, using test benchmark command:
python benchmark_client.py --detailed --username user --ontologies_ids 1 10 --server_url http://127.0.0.1:8080/api/v0 --token abcd, the update method fails with the dictionary key error for key value 'unstructured'.

Reason is that the PUT request is provided by Java adapter as DataMessage with addressing_mode=0 (meaning the DataMessage body contains the actual request payload, in this case entire multipart/form-data content), while the handler method assumes addressing_mode=2 (uploaded files are transmitted separately from the DataMessage).

Because the actual files are encoded in the multipart message itself rather than sent via separate queue, while the handler still expects the extra_data dictionary, associated with addressing_mode=2, to have reference to temp file, in order to build UploadedFile class instance. However in the addressing_mode=0, the arg value already IS UploadedFile instance and needs not a conversion (and the extra_data dictionary, capturing the separate file uploads, is empty, because there are no separate queue file uploads.

Ref epic: [CleverSwarm Onboarding #58](https://git.cleverthis.com/clevermicro/clevermicro/issues/58) while testing update function of CleverSwarm integration, using test benchmark command: `python benchmark_client.py --detailed --username user --ontologies_ids 1 10 --server_url http://127.0.0.1:8080/api/v0 --token abcd`, the update method fails with the dictionary key error for key value 'unstructured'. Reason is that the PUT request is provided by Java adapter as DataMessage with addressing_mode=0 (meaning the DataMessage body contains the actual request payload, in this case entire multipart/form-data content), while the handler method assumes addressing_mode=2 (uploaded files are transmitted separately from the DataMessage). Because the actual files are encoded in the multipart message itself rather than sent via separate queue, while the handler still expects the extra_data dictionary, associated with addressing_mode=2, to have reference to temp file, in order to build UploadedFile class instance. However in the addressing_mode=0, the arg value already IS UploadedFile instance and needs not a conversion (and the extra_data dictionary, capturing the separate file uploads, is empty, because there are no separate queue file uploads.

Rows
Columns