Java plugin supports serializing/deserializing class information in callback context , this plugin doesnt support that today.
Use case, related to #243. Say I want to store a datetime.datetime object. Right now it gets returned as a string, so the next time I use it when I am called back, it comes across as a string not as an original datetime object.
I confirmed this on the handler side by printing out a ProgressEvent post serialization.
{'message': '', 'callbackContext': {'resource_entry_end_time': datetime.datetime(2023, 1, 19, 16, 25, 19, 5602), 'handler_entry_time': datetime.datetime(2023, 1, 19, 16, 23, 19, 5606), 'working_model': ResourceModel(...), 'create_action1_completed': True, 'create_action1_request_id': '1234'}, 'callbackDelaySeconds': 1, 'resourceModel': {...}, 'status': 'IN_PROGRESS'}
Received on the cfn test side for contract testing:
{'message': '', 'callbackContext': {'resource_entry_end_time': '2023-01-19T16:25:19.005602', 'handler_entry_time': '2023-01-19T16:23:19.005606', 'working_model': {...}, 'create_action1_completed': True, 'create_action1_request_id': '1234'}, 'callbackDelaySeconds': 1, 'resourceModel': {....}, 'status': 'IN_PROGRESS'}
So if we attempt to store any non-primitive type its replaced with a string representation and no way to get back to it. This requires handler authors, if they want to use complex types, to do their own marshalling.