explore how to handle `reply` operation in code generation

[derberg]

example from Slack and Hopscotch/Postman (one of these 2) has an operation that also has reply operation. This means that given application, whenever gets a message or sends a message, sends or receives a reply. We need to generate code that support is.

so for example in Slack, whenever you get a regular event, you need to reply with envelopeId. We need a code generated that will for example for client not only read an incomming message and allow you to write business logic for it, but also gives you an easy to use function to send a reply

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[derberg]

it's still needed, I'll submit it under bounty. We have slack example where we have request/reply pattern - sending ack message back to the server whenever event is received.

[derberg]

expected outcome:

• clear information on
  • if this is possible
  • how information should be provided in AsyncAPI document to get proper code generated
  • what workarounds are needed, and if only workarounds - issue in spec repo should be defines
• implementation in one of the templates using slack example: code and test

more:

• I'll work on it
• It is advanced issue

[aeworxet]

Bounty Issue's service comment

Text labels: bounty/2025-Q4, bounty/advanced, bounty/coding, bounty/canceled, bounty/eol
First assignment to regular contributors: 2025-09-19 00:00:00 UTC+12:00
End Of Life after: 2025-10-31 23:59:59 UTC-12:00

@asyncapi/bounty_team

The Bounty Program is not a Mentorship Program. The accepted level of Bounty Program Participants is Middle/Senior.

Regular contributors should explain in meaningful words how they are going to approach the resolution process when expressing a desire to work on this Bounty Issue.

[aeworxet]

Following the expression of desire to work on this Bounty Issue, @derberg (githubID: 6995927) is an AsyncAPI Maintainer specified in the file https://github.com/asyncapi/community/blob/master/MAINTAINERS.yaml, so they fall under the first category in the prioritization list.

[aeworxet]

Bounty Issue's Timeline

Complexity Level	Assignment Date (by GitHub)	Start Date (by BP Rules)	End Date (by BP Rules)	Draft PR Submission	Final PR Merge Start	Final PR Merge End
Advanced	2025-09-16	2025-10-06	2025-11-30	2025-10-26	2025-11-16	2025-11-30

Please note that the dates given represent deadlines, not specific dates; so if the goal is reached sooner, it's better.

Keep in mind the responsibility for violations of the Timeline.

Assignee: @derberg (githubID: 6995927)

[naaa760]

Hello! @derberg!
I’d like to work on this issue. Could you please assign it to me?
still anyone working on ??