Skip to content
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

Long values are not sent correctly with PubSub #686

Closed
yschneider-bosch opened this issue Feb 15, 2022 · 9 comments · Fixed by #713
Closed

Long values are not sent correctly with PubSub #686

yschneider-bosch opened this issue Feb 15, 2022 · 9 comments · Fixed by #713
Assignees
Labels
kind/bug Something isn't working P1 size/S triaged/resolved Items triaged and ready
Milestone

Comments

@yschneider-bosch
Copy link

In what area(s)?

/area runtime

What version of Dapr?

1..5.0

Expected Behavior

Events with Long values are sent and received correctly.

Actual Behavior

Large long values are slightly different when received by the consumer. For example when the value 590518626939830271 is sent, the event received by the consumer has the value 590518626939830300.

Steps to Reproduce the Problem

The pubsub example was adjusted to demonstrate this issue:

Publisher.java

...
/**
   * This is the entry point of the publisher app example.
   * @param args Args, unused.
   * @throws Exception A startup Exception.
   */
  public static void main(String[] args) throws Exception {
    try (DaprClient client = new DaprClientBuilder().build()) {
      for (int i = 0; i < NUM_MESSAGES; i++) {
        String message = String.format("This is message #%d", i);
        //Publishing messages
        client.publishEvent(
            PUBSUB_NAME,
            TOPIC_NAME,
            new WithLong(590518626939830271L),
            singletonMap(Metadata.TTL_IN_SECONDS, MESSAGE_TTL_IN_SECONDS)).block();
        System.out.println("Published message: " + message);

        try {
          Thread.sleep((long) (1000 * Math.random()));
        } catch (InterruptedException e) {
          e.printStackTrace();
          Thread.currentThread().interrupt();
          return;
        }
      }

      // This is an example, so for simplicity we are just exiting here.
      // Normally a dapr app would be a web service and not exit main.
      System.out.println("Done.");
    }
  }

WithLong.java


package io.dapr.examples.pubsub.http;

public class WithLong {
  public Long value;

  public WithLong(Long value) {
    this.value = value;
  }

  public WithLong() {

  }


}

SubscriberController.java

 ...
  /**
   * Handles a registered publish endpoint on this app.
   * @param cloudEvent The cloud event received.
   * @return A message containing the time.
   */
  @Topic(name = "testingtopic", pubsubName = "${myAppProperty:messagebus}")
  @PostMapping(path = "/testingtopic")
  public Mono<Void> handleMessage(@RequestBody(required = false) CloudEvent<WithLong> cloudEvent) {
    return Mono.fromRunnable(() -> {
      try {
        System.out.println("Subscriber got: " + cloudEvent.getData());
        System.out.println("Subscriber got: " + cloudEvent.getData().value);
      } catch (Exception e) {
        throw new RuntimeException(e);
      }
    });
  }
...

Results when running the modified example:


INFO[0004] dapr initialized. Status: Running. Init Elapsed 4536.042ms  app_id=subscriber instance=MacBook-Pro-von-Yoav.local scope=dapr.runtime type=log ver=1.6.0
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@644c09e5
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@1a0d2d33
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@932cc54
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@206ed09f
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@1c216f73
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@7b64ed98
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@4ef7c13c
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@793a10ba
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@178d181a
== APP == Subscriber got: 590518626939830300
== APP == Subscriber got: io.dapr.examples.pubsub.http.WithLong@6920325d
== APP == Subscriber got: 590518626939830300

Release Note

RELEASE NOTE:

@yschneider-bosch yschneider-bosch added the kind/bug Something isn't working label Feb 15, 2022
@artursouza artursouza added P1 size/S triaged/resolved Items triaged and ready labels Feb 16, 2022
@artursouza artursouza modified the milestones: v1.6, v1.5 Feb 16, 2022
@tanvigour
Copy link
Contributor

/assign

@mukundansundar
Copy link
Contributor

I think this might be related to dapr/dapr#3837.

@shubham1172
Copy link
Member

It is! @mukundansundar

@mukundansundar
Copy link
Contributor

I think we need to add a simple test in the IT suite for pubsub to test for this scenario and create a PR for the same here. So that once the fix is merged in dapr, we can verify it is also fixed via the SDK.

@tanvigour
Copy link
Contributor

Thanks @mukundansundar I'll add the test for this in pubsub and create a PR. Any estimate on when this fix will be merged?

@shubham1172
Copy link
Member

@tanvigour we are targeting it for v1.7

@mukundansundar
Copy link
Contributor

@tanvigour The fix was merged few minutes back in components-contrib .... This needs to be picked up in runtime.

@mukundansundar
Copy link
Contributor

@tanvigour Can probably finish this once dapr/dapr#4409 is merged ....

@tanvigour
Copy link
Contributor

yes! keeping an eye on it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Something isn't working P1 size/S triaged/resolved Items triaged and ready
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants