purgeEndpoints fails if endpoint was not used before

[ceazy79]

Citrus Version tested with 2.7.6

Expected behavior Calling purgeEndpoints with an endpoint that was not used to send messages has the same behaviour as calling the method with an endpoint that has no messages in the queues anymore because they already are consumed. In my case this problem occurred in a larger integration test where one execution path lead to the situation that no messages where sent. But the purgeEndpoints method was called at the end of one step in the test to ensure that no messages are present in the queues before executing the next steps of the test.

Actual behavior Calling purgeEndpoints with an endpoint that was not used to send messages leads to an exception: CitrusRuntimeException: Failed to get correlation key for 'citrus_message_correlator_[clientId]'

Whereas calling the method with an endpoint with no messages results in a log entry: DEBUG com.consol.citrus.actions.PurgeEndpointAction - Purged 0 messages from endpoint

Test case sample `public class PurgeEndpointTest extends TestNGCitrusTestRunner {

@CitrusEndpoint @HttpClientConfig(requestUrl = "http://localhost:8080")
private HttpClient todoClient;

@CitrusEndpoint @HttpServerConfig(autoStart = true)
private HttpServer todoServer;

@CitrusTest
@Test
public void testPurgeEndpointWorks() {
    send(builder -> builder.endpoint(todoClient).payload("some text"));
    receive(builder -> builder.endpoint(todoClient));
    purgeEndpoints(builder -> builder.endpoint(todoClient));
}

@CitrusTest @Test
public void testPurgeEndpointNotWorking() {
    purgeEndpoints(builder -> builder.endpoint(todoClient));
}

}`

Hint The problem is located in the PollingCorrelationManager in line 95 to 97. Maybe it is possible to not throw an exception here but log, e.g. a warning.

best regards, Chris

[christophd]

This is an interesting scenario that I have never had before. But I can imagine what went wrong here.

I assume you are using a synchronous endpoint. As the endpoint can be used bidirectional (send request and receive synchronous response or receive request and send synchronous response) the endpoint makes a guess which direction to use based on the first operation on it.

So in case the 1st operation is a receive the endpoint act as a consumer and needs to operate with a synchronous response when using send. The other way round when the 1st operation is a send the endpoint acts as producer and waits for a synchronous response to arrive. The endpoint direction is finally so once the endpoint made its guess on the direction the endpoint is marked as producer or consumer for the rest of the complete test run.

So in your case the purge operation marked the endpoint as a synchronous consumer. Following from that your send operation in the test would act as synchronous response producer. But the endpoint did not find a request to match the response and this leads to the error.

I would suggest to use another asynchronous endpoint on that same queue that is only used for the purge operations. So the synchronous endpoint is marked as producer as you need it to be.

[svettwer]

Hi!

We've discussed the issue and agreed that this is a rare corner case where your want to purge an endpoint that hasn't been used before. Nevertheless, one should provide idempotency to the operation as an enhancement to the framework.

BR, Sven