Oneway service request from the command line

[caguero]

🦟 Bug fix

Partially fixes #97

Summary

This patch makes it possible to request a one-way service request from the command line. Before, it was possible passing --reptype gz.msgs.Empty but always getting the message Service call timed out as an output (because the service callback wasn't answering anything, which was expected).

How to test it?

You can compile the examples, and then:

1. Launch the one-way responser:

./responser_oneway

2. Request the service using the two-way request and verify that you don't get the timeout:

gz service -s /oneway --reqtype gz.msgs.StringMsg --reptype gz.msgs.Empty --req 'data: "Hello"' --timeout 1000

3. Use the new one-way request and verify that you don't get the timeout message:

gz service -s /oneway --reqtype gz.msgs.StringMsg --req 'data: "Hello"'

Note that both requests should reach the responser:

Request received: [Hello]
Request received: [Hello]

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 87.67%. Comparing base (eac2e69) to head (687edcc).
Report is 3 commits behind head on gz-transport13.

Additional details and impacted files

@@                Coverage Diff                 @@
##           gz-transport13     #477      +/-   ##
==================================================
- Coverage           87.69%   87.67%   -0.03%     
==================================================
  Files                  59       59              
  Lines                5704     5710       +6     
==================================================
+ Hits                 5002     5006       +4     
- Misses                702      704       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[azeey]

Would it be possible to detect that the response type is Empty instead of relying on the timeout to decide that the request is one way? I like the idea of making some of the arguments optional (see #475, #474, #473), but there is a lot of existing documentation that uses the --reptype gz.msgs.Empty and --timeout arguments. It would be nice if those commands didn't timeout as well.

[caguero]

26d669b

Sounds good to me. Then, now both:

gz service -s /oneway --reqtype gz.msgs.StringMsg --reptype gz.msgs.Empty --req 'data: "Hello"' --timeout 10

and

gz service -s /oneway --reqtype gz.msgs.StringMsg --req 'data: "Hello"'

shoudn't generate timeouts.

[caguero]

@j-rivero , do you know why the same job (Ubuntu CI / Ubuntu Jammy CI) can pass and fail at the same time? It seems that GZ_PATH and g_gzVersion is undefined.

[azeey]

There have been some changes in #481 that affect this PR. I suggest merging from gz-transport13.

[caguero]

Good to go again!

[azeey]

LGTM! Just one comment about the timeout.

[azeey]

Users might expect a timeout of -1 as "wait forever", which would be the opposite of this. I would say just checking if the message type is Empty is sufficient, but if you think we should have the timeout check as well, we should definitely update the help message of the CLI to mention this.

[caguero]

I think it's fine just checking the response type. I updated it in 687edcc.