Investigate whether ancesteor fields of TransitionInstantiationCmd needs to be added to serialisation and deserialisation

[PHWaechtler]

This is a follow up from this PR discussion. The serialisation oversight that led to the bug described for startAfter and startBefore commands is also present in TransitionInstantiationCmd: this command has a field for the ancestor Id, but this field is not being serialised/deserialised. It is currently unclear if that is intentional or a bug. We can investigate this by clarifying whether the ancestor field is relevant to TransitionInstantiationCmd both in terms of business use case and in terms of BE code. The testing steps may be similar to the ones described startBefore/startAfter ticket, just instead using the TransitionInstantiationCmd - unsure if we can reuse the same example project here.

Acceptance Criteria (Required on creation)

• investigate whether the ancestor field in TransitionInstantiationCmd that is currently not respected during serialisation and deserialisation is relevant to async command execution and should be added to serialisation/deserialisation
• If if needs to be added to (de)serialisation, this can be considered a bug and should be fixed with the same changes as we've done for the startBefore and startAfter commands in this ticket
• If we do not need to serialise this ancestor field, the task can be considered completed without changes to the codebase

Hints

If this is a bug, these changes can most likely be "copied" from the fix for the startBefore/startAfter commands

Links

Original issue
PR discussion

Breakdown

Pull Requests

Preview Give feedback

No tasks being tracked yet.

Dev2QA handover

• Does this ticket need a QA test and the testing goals are not clear from the description? Add a Dev2QA handover comment