In Kafka Streams binder, we need to exclude the SendToDlqAndContinue
BiFunction by adding it to the ineligible function definitions.
See this commit for more context: 8ec15fa3ca
When DLQ is enabled on a consumer binding, the internal producer properties
used by the DLQ mechanism to send to the topic is not populated with the
correct binding name. In the previous version, it was working fine since
we were relying on a ThreadLocal. This is revamped recently to properly
introduce a binding name as a top level property in ProducerProperties.
However, this was not set on the internal producer properties used by the
DLQ. This PR addresses this issue.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2417Resolves#2418
* Refactor SerdeResolverUtils logic
* Add more tests in SerdeResolverUtilsTests
* Fixed some random test warnings
Fixes#2370
Code review feedback: remove FQ ref to inner method
Fix checkstyles
Make binding names available through Consumer/Producer properties.
Currently, the binders use a ThreadLocal to store the binding name for internal use.
These changes introduce the binding name as a property for both producer/consumer bindings.
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2380
Fixes https://github.com/spring-cloud/spring-cloud-stream/issues/2359
The KCL mode does not apply at the moment `AT_TIMESTAMP` and `TRIM_HORIZON` initial offsets
Resolves#2365
* Change the `KinesisMessageChannelBinder` binder logic to create an explicit
`KinesisClientLibConfiguration` based on the provided properties including
custom stream iterator type
* Adjust `KinesisTestBinder` to be able to create a KCL/KPL based bindings
Fixes https://github.com/spring-cloud/spring-cloud-stream/issues/2311
* Use Tescontainers for Localstack
* Fix tests according new `core` status quo
* Improve `KinesisStreamProvisioner` to wait for stream become active
before moving on to other logic
Disable Kinesis binder LocalstackContainerTest on mac
Resolves https://github.com/spring-cloud/spring-cloud-stream/issues/2307
- when creating `Declarables` beans for redeclaration after a connetion failure
2 DLX/DLQ bindings used the same bean name so the second one was never recovered/
- removing consumer `Declarable` beans from the `autoDeclareContext` was incomplete
- removing producer `Declarable` beans was not performed at all
- fix bean names; fix cleanup; add tests for all config scenarios
- check cleanup in all `RabbitBinderTests`
**cherry-pick to 3.2.x when the mono repo is established**
Resolves#2309
