-
Notifications
You must be signed in to change notification settings - Fork 69
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
Return type definition of Kafka.structured seems incorrect #487
Comments
After looking a little more at this today, it seems as though the Binding might need to support a generic(s) to pass the necessary structure(s) down to the Serializer? Currently the more specific structures are lost, and the type end up using the plain |
Yep I think I'm seeing the same issue, but in the reverse. When consuming a Kafka message, I want to convert it back into an abstract CloudEvent. I can use export interface Message<T = string> {
headers: Headers;
body: T | string | Buffer | unknown;
} This is a bit confusing because This means in order to actually generate a valid CloudEvent from the incoming Kafka message I'm forced to cast the argument. Without casting an Error is raised. const myCloudEvent: CloudEventV1<string> = Kafka.toEvent({
headers,
key,
value,
body,
} as Message); Happy to help out if there is consensus this could be improved, I just can't tell if it's me misinterpreting how the SDK was designed or not. |
@FelixHarvey @evanshortiss thank you for your detailed descriptions of the issues you are seeing with the SDK - and I would welcome any contributions you have towards improvement. The interfaces are a bit clumsy. The sdk-javascript/src/message/index.ts Lines 25 to 30 in d9ee0e0
I want this to be generic so that various protocols such as HTTP and Kafka, which have differing implementations can all behave similarly when serializing and deserializing CloudEvent messages. The sdk-javascript/src/message/index.ts Lines 63 to 79 in d9ee0e0
However, the result is what you are seeing now. There is some amount of type casting that is inevitable. If you have ideas or suggestions to improve this situation, I'd be more than happy to talk about them. |
This issue is stale because it has been open 30 days with no activity. |
This issue is stale because it has been open 30 days with no activity. |
This issue is stale because it has been open 30 days with no activity. |
I am facing the same issue. I implemented a workaround by casting to import { Message } from 'kafkajs';
import { Kafka as CloudEventsKafka } from 'cloudevents';
const message = CloudEventsKafka.structured(cloudEvent) as any as Message; |
This issue is stale because it has been open 30 days with no activity. |
Describe the Bug
The types for return values from
Kafka.structured(cloudEventInstance)
seem to be incorrect. The returned object has the following structure if viewed using logs or a debugger:However, the types come from
CE.Message<string>
. This results in the following intellisense structure being suggested:It seems as though the headers key is correct, but the body is incorrect, and other keys are missing.
Steps to Reproduce
new ce.CloudEvent({ type: 'foo', source: 'bar', data: { hello: 'world' }, partitionkey: 'foobar' }
Kafka.structured(theEvent)
unknown
Expected Behavior
I would have expected the types to reflect the Object in the Describe the bug section, e.g:
Is this an invalid assumption to make? Passing the result of
Kafka.structured(cloudEventInstance)
object to a Kafka client such as KafkaJS requires casting the object to access the necessary properties to satisfy the TS compiler. It seems like this casting should be unnecessary.Additional context
I'm using version 6.0.1 of the cloudevents module. The image below might help provide some context.
The text was updated successfully, but these errors were encountered: