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

websocket server sends duplicate message headers in protos response #246

Closed
mjay-cr opened this issue Feb 8, 2024 · 4 comments · Fixed by #281
Closed

websocket server sends duplicate message headers in protos response #246

mjay-cr opened this issue Feb 8, 2024 · 4 comments · Fixed by #281
Assignees
Labels
bug Something isn't working

Comments

@mjay-cr
Copy link

mjay-cr commented Feb 8, 2024

Environment

  • OS Version: Ubuntu 20.04
    Binary gz-harmonic package from ubuntu-stable

Description

  • Expected behavior: Running shapes.sdf simulation, then websocket server and connecting with web app shows visualisation of simulation in browser.
  • Actual behavior: Nothing happens when you click connect, looking at console log gives error.

Steps to reproduce

  1. Install gz-harmonic
  2. On a terminal run gz sim -v 4 -s -r shapes.sdf
  3. In another terminal run gz launch -v 4 /usr/share/gz/gz-launch7/configs/websocket.gzlaunch
  4. Go to web app and click connect

Output

If you open up the dev-tools on the browswer and then look at console, you will see the error:

ERROR Error: duplicate name 'Any' in Namespace .gz.msgs
    add namespace.js:240
    parseType parse.js:354
    parseCommon parse.js:261
    parse parse.js:790
    onloadend gzweb.module.js:11673

Switching to network and filtering by WebSocket requests, you will see that gzweb sends protos request. (Looking at the gz_launch console log will also show that it has been received). Then the response, when viewed as UTF-8 will see the proto headers sent below. After Wrench message it seems to repeat? Response from gz-garden and gz-harmonic are attached. Note: that the web visualisation works with garden and fortress (as per the steps above)

gz-garden-response.txt
gz-harmonic-response.txt

Not sure if these duplicate headers are the problem but seems like a bug

@mjay-cr mjay-cr added the bug Something isn't working label Feb 8, 2024
@hughlv
Copy link

hughlv commented Apr 29, 2024

Before this issue gets solved, what is the best workaround? I need to run gazebo as a websocket server so I can use gzweb2 to render on webpage.

@mjay-cr
Copy link
Author

mjay-cr commented Apr 29, 2024

Before this issue gets solved, what is the best workaround? I need to run gazebo as a websocket server so I can use gzweb2 to render on webpage.

Not sure if this is helpful but my current "workaround" is to just not migrate to harmonic, this is the only thing that is stopping me from migrating from fortress.

@VincidaB
Copy link

VincidaB commented Oct 8, 2024

After some testing, I was able to see that WebsocketServer.cc seem to receive the types in double on this line :

 gz::msgs::Factory::Types(types);

This would make it an issue with gz-msgs probably.

I was able to come-up with a dirty fix on the gz-launch side :

std::set<std::string> processedDescriptors;

// Get all the messages, and build a single proto to send to the client.
for (auto const &type : types)
{
  auto msg = gz::msgs::Factory::New(type);
  if (msg)
  {
    auto descriptor = msg->GetDescriptor();
    if (descriptor){
      std::string descriptorStr = descriptor->DebugString();
      std::string firstLine = descriptorStr.substr(0, descriptorStr.find('\n'));
      if (processedDescriptors.find(firstLine) != processedDescriptors.end())
      {
        gzdbg << "Skipping duplicate descriptor[" << firstLine << "]\n";
        continue; // Skip if the first line of the descriptor has already been processed
      }
      allProtos += descriptorStr;
      gzdbg << descriptorStr;
      processedDescriptors.insert(firstLine); // Mark this descriptor as processed
    }
    else
    {
      gzerr << "Failed to get the descriptor for message["
        << type << "]\n";
    }
  }
  else
  {
    gzerr << "Failed to build message[" << type << "].\n";
  }
}

@iche033
Copy link
Contributor

iche033 commented Oct 11, 2024

I created a couple of PRs:

I think that may fix the issue. I was able to get shapes.sdf working after these changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

5 participants