feat: add support for reply in python websocket client

[derberg]

resolved #1547 that depends on #1548

Reply is possible in cool way with correlationId

This PR contains at the moment only changes in fixtures. Slack example nicely shows that it is recommended that for handling reply it is critical to specify correlationId so it is not only from the docs perspective but also from code generation perspective useful to know how incomming message is correlated with the reply message, with what properties.

With correlationId in place, you can generate code that is aware of a specific correlationId property and enable access to it through dedicated arguments.

Current Limitation

Why dependency?

Current problem is that for clients we generate a generic message handler for a given address. Looking at this from perspective of Slack client, it means we have one handler for all incomming messages, onHelloMessage, onEvent, onDisconnectMessage. The user of the generated client on their own needs to write code that can help understand what type of message was received by the handler.

So if onEvent is the only message that requires reply, developer needs to write a code inside message handler that understands that onEvent message was received, and then reply.

At the moment there is nothing useful that could be generated.

I could enable user to do client.register_reply_handler('onEvent', reply_handler_with_correlation) but what is the value really?

message handler could use some new function like:

self.send_reply('onEvent', reply_message)

But we are stuck with generic solutions again, generic message handler and generic reply handler - I don't like it at all.

Reply as standalone operation

Current slack example has:

operations:
  onEvent:
    action: receive
    channel:
      $ref: '#/channels/root'
    messages:
      - $ref: '#/channels/root/messages/event'
    reply:
      messages:
        - $ref: '#/channels/root/messages/acknowledge'
      channel:
        $ref: '#/channels/root'

We could do this to at least enable generation of standalone method to send reply"

operations:
  onEvent:
    action: receive
    channel:
      $ref: '#/channels/root'
    messages:
      - $ref: '#/channels/root/messages/event'
    reply:
      messages:
        - $ref: '#/channels/root/messages/acknowledge'
      channel:
        $ref: '#/channels/root'
  sendEventAcknowledge:  # NEW: Explicit reply send operation
    action: send
    messages:
      - $ref: '#/channels/root/messages/acknowledge'

But this is controversial and enables errors, for example I can have different channel in reply and a different channel specified in sendEventAcknowledge. So to be honest best would be to enable reply object to simply have operationId or I would just have to generate onEvent + Reply as standalone function.

Some discussion under: asyncapi/spec#981

---

So again, we should first solve #1548 and then we can handle reply topic, because the best user experience would be if I get access to handler like client.register_onevent_reply_handler(my_reply_method) that allows me to pass my_reply_method that would have access to incoming message and correlationId and it's goal would be to return object that would be sent to the server/broker

[changeset-bot]

⚠️ No Changeset found

Latest commit: c28946f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[asyncapi-bot]

What reviewer looks at during PR review

The following are ideal points maintainers look for during review. Reviewing these points yourself beforehand can help streamline the review process and reduce time to merge.

1. PR Title: Use a concise title that follows our Conventional Commits guidelines and clearly summarizes the change using imperative mood (it means spoken or written as if giving a command or instruction, like "add new helper for listing operations")

   Note - In Generator, prepend feat: or fix: in PR title only when PATCH/MINOR release must be triggered.

2. PR Description: Clearly explain the issue being solved, summarize the changes made, and mention the related issue.

   Note - In Generator, we use Maintainers Work board to track progress. Ensure the PR Description includes Resolves #<issue-number> or Fixes #<issue-number> this will automatically close the linked issue when the PR is merged and helps automate the maintainers workflow.

3. Documentation: Update the relevant Generator documentation to accurately reflect the changes introduced in the PR, ensuring users and contributors have up-to-date guidance.

4. Comments and JSDoc: Write clear and consistent JSDoc comments for functions, including parameter types, return values, and error conditions, so others can easily understand and use the code.

5. DRY Code: Ensure the code follows the Don't Repeat Yourself principle. Look out for duplicate logic that can be reused.

6. Test Coverage: Ensure the new code is well-tested with meaningful test cases that pass consistently and cover all relevant edge cases.

7. Commit History: Contributors should avoid force-pushing as much as possible. It makes it harder to track incremental changes and review the latest updates.

8. Template Design Principles Alignment: While reviewing template-related changes in the packages/ directory, ensure they align with the Assumptions and Principles. If any principle feels outdated or no longer applicable, start a discussion these principles are meant to evolve with the project.

9. Reduce Scope When Needed: If an issue or PR feels too large or complex, consider splitting it and creating follow-up issues. Smaller, focused PRs are easier to review and merge.

10. Bot Comments: As reviewers, check that contributors have appropriately addressed comments or suggestions made by automated bots. If there are bot comments the reviewer disagrees with, react to them or mark them as resolved, so the review history remains clear and accurate.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud