Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

OpenAPI plugin: allow an operation to both be received and trigger an outbound message (e.g. a command published to a queue)

Open
  • Is something wrong?
#449 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
openapi, typescript
Domain
api, tooling

Research direction

Start by locating the OpenAPI generator handling for x-eventcatalog-message-action and the existing consumers feature. Define how x-eventcatalog-sends resolves message id/version and handles missing messages, then verify that the operation retains its receives entry while adding outbound messages to the service's sends list.

Written by the indexing model from the issue text.

Description

Use Case

Today x-eventcatalog-message-action is an either/or choice: an operation is documented as either sends or receives. In a common async pattern neither option alone is correct.

Use case

Our API accepts a synchronous command (e.g. POST /orders → PlaceOrder). The HTTP handler does not do the actual work: it validates the request and sends a different command onto a queue (e.g. ProcessOrder), which is picked up by a worker that performs the real processing.

We want the catalog to show both hops:

Client → PlaceOrder (HTTP command, received by Orders API) → Orders API → ProcessOrder (command on queue) → Order Worker

Right now we can only document one side. Marking the operation sends hides that the API receives the HTTP command; leaving it as receives hides the queue hop entirely, so the visualiser stops at the API and the async part of the flow is invisible.

Proposed Solution

Allow an operation to declare outbound messages in addition to its own action, referencing messages that already exist in the catalog (typically generated by the AsyncAPI generator) by id and optional version:

paths:
  /orders:
    post:
      summary: Place an order
      operationId: placeOrder
      x-eventcatalog-message-type: command
      x-eventcatalog-message-action: receives   # unchanged, still documented
      # New: what handling this operation publishes
      x-eventcatalog-sends:
        - id: process-order
          version: 1.0.0

The generator would add these messages to the service's sends list, leaving the existing receives entry intact. Semantics could mirror the existing consumers feature: look up the message by id/version, skip (with a warning) if it does not exist, and document the ordering requirement that the generator producing those messages must run first.

Implementation Notes

No response

Community Notes
  • Please vote by adding a 👍 reaction to the issue to help us prioritize.
  • If you are interested to work on this issue, please leave a comment.
  • If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out in the EventCatalog Discord.
Dominant language
TypeScript
Stars
15
Forks
16
Avg merge
2m
Merged PRs (30d)
3

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from event-catalog/generators

All issues in event-catalog/generators

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.