Removing 2 messaging contract types - leaving just the "supplier" version

[marcingrzejszczak]

done via 1999066

[kwonglau]

What is the migration path for "Output Triggered by a Message" ?

Currently, the java microservice framework is using spring cloud contract 3.x and it is depending on that for contract testing

https://github.com/eventuate-tram/eventuate-tram-core/blob/master/eventuate-tram-spring-testing-support-cloud-contract/src/main/java/io/eventuate/tram/spring/cloudcontractsupport/EventuateTramRoutesConfigurer.java#L53

[marcingrzejszczak]

Check this page https://github.com/spring-cloud/spring-cloud-contract/wiki/Spring-Cloud-Contract-4.0-Migration-Guide#leave-only-code-input-triggers-and-output-message-type

[keydon]

hmm very sad you are letting the inputMessage feature go. Most of our rabbit-endpoints are following the request-response pattern. So for me it is exactly the same use-case as an http-endpoint. but now if I understand it right its no longer testable with a single contract and without code :( I guess I would need to write at least two contracts, wire-in a stub-runner for each-client. And I would need to trigger a producer-stub-within a consumer-trigger. A lot of moving parts for a simple RPC-Call.

But since I am the only one who is sad to see this feature go I guess its not coming back, is it?
Now I am thinking about adding a HTTP-Wrapper around my Rabbit-RPC-Endpoints. So I can still have a single contract, and the custom HTTP-Wrapper can be generic and reusable for every other test. Or is there an easier way to test a RPC-Endpoint? Maybe you could add a RCP Example to the other examples repo.

and btw. all the docs about the contracts that I came across are still on the old version and still advertising this cool inputMessage feature.

[marcingrzejszczak]

hmm very sad you are letting the inputMessage feature go. Most of our rabbit-endpoints are following the request-response pattern. So for me it is exactly the same use-case as an http-endpoint. but now if I understand it right its no longer testable with a single contract and without code :( I guess I would need to write at least two contracts, wire-in a stub-runner for each-client. And I would need to trigger a producer-stub-within a consumer-trigger. A lot of moving parts for a simple RPC-Call.

Yes, you need to write 2 separate contracts indeed.

But since I am the only one who is sad to see this feature go I guess its not coming back, is it?

It's definitely not coming back :)

Now I am thinking about adding a HTTP-Wrapper around my Rabbit-RPC-Endpoints. So I can still have a single contract, and the custom HTTP-Wrapper can be generic and reusable for every other test. Or is there an easier way to test a RPC-Endpoint? Maybe you could add a RCP Example to the other examples repo.

The easiest way to do that will be to have 2 separate contracts IMO.

and btw. all the docs about the contracts that I came across are still on the old version and still advertising this cool inputMessage feature.

I found only 2 mentions in main and I've just removed them.

[keydon]

about the outdated docs, I mean the published ones here:
https://cloud.spring.io/spring-cloud-contract/reference/html/project-features.html#features-messaging-scenario2 seems to be based on the old "3.0.0-SNAPSHOT" sources

[marcingrzejszczak]

These are old docs that have been migrated away from years ago. This is the latest version of the docs https://docs.spring.io/spring-cloud-contract/docs/current/reference/html/

[keydon]

seems nobody told google about it ;O