smbecker opened a new issue, #260:
URL: https://github.com/apache/pulsar-dotpulsar/issues/260
### Description
I have a topic that was created using `NewConsumer(Schema.String)`. However,
for retries and dead letters, I frequently create the producers using
`NewProducer()` since I don't want to pay the `Encode`/`Decode` penalty since
it is just forwarding the message data from the consumer into the retry queue.
After upgrading to 4.2, I noticed that my retry producers were faulting with a
`IncompatibleSchemaException`.
### Reproduction Steps
```c#
[Fact]
public async Task can_publish_retry_to_consumer() {
var pulsarContainer = new PulsarBuilder().Build();
await pulsarContainer.StartAsync();
try {
await using var client = PulsarClient.Builder()
.ServiceUrl(new Uri(pulsarContainer.GetBrokerAddress()))
.Build();
await using var originProducer =
client.NewProducer(Schema.String)
.Topic("persistent://public/default/test")
.Create();
await using var originConsumer =
client.NewConsumer(Schema.String)
.Topic("persistent://public/default/test")
.SubscriptionName("test")
.SubscriptionType(SubscriptionType.Exclusive)
.Create();
await using var retryProducer = client.NewProducer()
.Topic("persistent://public/default/test")
.Create();
await originProducer.Send("test");
var testMessage = await originConsumer.Receive();
Assert.Equal("test", testMessage.Value());
await retryProducer.Send(testMessage.Data);
testMessage = await originConsumer.Receive();
Assert.Equal("test", testMessage.Value());
} finally {
await pulsarContainer.StopAsync();
}
}
```
### Expected behavior
Technically, this is more accurate in creating the topic with the correct
schema. However, it is a change in behavior and not one that was expected.
Perhaps a flag that allows you to opt-out of setting the schema at the
server-side topic level to preserve the old behavior.
### Actual behavior
Throws a `ProducerFaultedException` with the following as the
`InnerException`:
```
DotPulsar.Exceptions.IncompatibleSchemaException:
org.apache.pulsar.broker.service.schema.exceptions.IncompatibleSchemaException:
Incompatible schema: exists schema type STRING, new schema type NONE caused by
org.apache.pulsar.broker.service.schema.exceptions.IncompatibleSchemaException:
Incompatible schema: exists schema type STRING, new schema type NONE
```
### Regression?
I would consider this a regression as it is a change in behavior and not one
that was expected.
### Known Workarounds
One workaround is to create all producers and consumers using
`ReadOnlySequence<byte>` and handle encoding and decoding yourself. Another
workaround is to create a new `ISchema<string>` with
`Schema.ByteSequence.SchemaInfo`.
```c#
private sealed class CustomStringSchema : ISchema<string>
{
public static ISchema<string> Instance { get; } = new
CustomStringSchema();
public SchemaInfo SchemaInfo => Schema.ByteSequence.SchemaInfo;
public string Decode(ReadOnlySequence<byte> bytes, byte[]?
schemaVersion = null) {
return Schema.String.Decode(bytes, schemaVersion);
}
public ReadOnlySequence<byte> Encode(string message) {
return Schema.String.Encode(message);
}
}
```
### Configuration
* Which version of .NET is the code running on? `net9.0`
* Which version of DotPulsar are you using? `4.2.0`
* What OS and version, and what distro if applicable? `Ubuntu 24.04`
* What is the architecture (x64, x86, ARM, ARM64)? `x64`
* Do you know whether it is specific to that configuration? It doesn't
appear to be related to OS/.NET configuration at all. It seems to be a breaking
change from [this PR](https://github.com/apache/pulsar-dotpulsar/pull/253)
### Other information
_No response_
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
