Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TPM does not always use correlation ID in messages #3377

Closed
ronjaquensel opened this issue Aug 21, 2023 · 0 comments · Fixed by #3387
Closed

TPM does not always use correlation ID in messages #3377

ronjaquensel opened this issue Aug 21, 2023 · 0 comments · Fixed by #3387
Assignees
Labels
bug Something isn't working
Milestone

Comments

@ronjaquensel
Copy link
Contributor

Bug Report

Describe the Bug

When sending a message regarding a TransferProcess (e.g. for termination), the TransferProcessManager does not always use the same ID. For outgoing messages regarding a process, the process's correlation ID should be used, as this is shared between the two parties. For e.g. sending a TransferStartMessage, the correct ID is used:

var message = TransferStartMessage.Builder.newInstance()
                 .processId(process.getCorrelationId())

but in case of termination and completion, the process ID is used (which, if the message is sent by the provider, is not known to the consumer):

var message = TransferTerminationMessage.Builder.newInstance()
                ...
                .processId(process.getId())

This causes an error on the counter-party side, as the message can not be correlated to an existing process.

Expected Behavior

Each message regarding a TransferProcess contains an ID known to the counter-party.

Observed Behavior

Some messages contain an ID that is not known to the counter-party.

Possible Implementation

Set the process.getCorrelationId() for the processId on all messages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants