Skip to content

HTTP.toEvent is lacking the cloudevents specification and accepts invalid objects #597

Open

Description

@mhay-at-dvelop

Describe the Bug
I'm trying to implement a rest-api for nodejs application with this sdk-javascript. when using HTTP.toEvent Method it returns an Object even when its semantically invalid compared to the cloudevents specification. So for example if you not supply the "type" property the method returns a cloud-event object with a type property which is undefined. Also if not supplying the specversion property it sets this property in result with a default value "1.0". Specification says that this property must be supplied, not that it is optional with a default value.
In my mind the method must not return a cloudevent object if it conflicts with the cloudevent specification.

Steps to Reproduce

  1. Use example "Receiving events" from sdk-javascript documention
  2. Use Postman to send a cloudevent with following structure (without specversion and type):
    {
    "source":"Source as a URI spec#123",
    "id":"b25e2717-a470-45a0-8231-985a99aa9416",
    "time":"2019-11-06T11:08:00Z",
    "datacontenttype":"application/json",
    "data":{
    "much":"wow"
    }
    }
  3. Check returning result from HTTP.toEvent. Resulting object has now a default "specversion" property with value 1.0 and an "type" property with value "undefined".

Expected Behavior
Should return error or throw exception in the mentioned cases .

Activity

  1. changed the title [-]HTTP.toEvent is lacking the cloudevents definition and accepts invalid objects[/-] [+]HTTP.toEvent is lacking the cloudevents specification and accepts invalid objects[/+] on Nov 7, 2024
  2. github-actions commented on Dec 8, 2024

    @github-actions
    Contributor

    This issue is stale because it has been open 30 days with no activity.

  3. lholmquist commented on Aug 29, 2025

    @lholmquist
    Contributor

    Your assement on the issue with the type property being undefined when it is not specified is probably a bug, but i don't think there is really an issue with the specversion having a default value. I think most people are using a spec version of 1.0, so unless they are using v0.3, there isn't really a need to specify this. I believe this is also inline with how the other sdk's work regarding defaulting the specversion

  4. github-actions commented on Sep 29, 2025

    @github-actions
    Contributor

    This issue is stale because it has been open 30 days with no activity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions