fix(css): adjust spacing in announcement banner and navbar (#4495) #4501
Conversation
* feat: remove roadmap.md and replace links * Add target _blank to link
* Some cleanup * Fix lint workflow * Add README.md to examples folder * Replace machine-readable with JSON Schema * Fix broken links * Only lint the spec because all-contributors-bot data would be marked as broken * Move the specification to the spec folder
…epo (asyncapi#510) * chore: remove everything that is not related to the spec * fix wording on sponsors * Get review documents back
* chore: improve contributing guidelines * Fix typo * Clarify the role of the champion
…ss (asyncapi#516) * chore: add new issue and PR templates according to the new spec process * Improve issue and pr templates * Point to issue asyncapi#1 on community repo * Fix stawman PR template * Add frontmatter to default issue template * Add a single PR template
ci: update global workflows
Co-authored-by: asyncapi-bot <[email protected]>
* docs: update README.md [skip ci] * docs: update .all-contributorsrc [skip ci] Co-authored-by: allcontributors[bot] <46447321+allcontributors[bot]@users.noreply.github.com>
Co-authored-by: Lukasz Gornicki <[email protected]>
…le, ideas, review (asyncapi#569) * docs: update README.md [skip ci] * docs: update .all-contributorsrc [skip ci] Co-authored-by: allcontributors[bot] <46447321+allcontributors[bot]@users.noreply.github.com>
Co-authored-by: Dale Lane <[email protected]> Co-authored-by: Maciej Urbańczyk <[email protected]> Co-authored-by: Laurent Broudoux <[email protected]> Co-authored-by: nictownsend <[email protected]>
atharva038
requested review from
Mayaleeeee,
TRohit20,
akshatnema,
anshgoyalevil,
asyncapi-bot-eve,
derberg,
sambhavgupta0705 and
thulieblack
as code owners
❌ Deploy Preview for asyncapi-website failed.Built without sensitive environment variables
|
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Welcome to AsyncAPI. Thanks a lot for creating your first pull request. Please check out our contributors guide useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.
|
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-4501--asyncapi-website.netlify.app/ |
asyncapi-bot
requested review from
CBID2,
bandantonio,
devilkiller-ag and
vishvamsinh28
WalkthroughAdds GitHub templates, CI workflows for releases and validation, scripts for spec manipulation and example conversion/validation, many AsyncAPI example documents and shared example components, documentation for the release process, minor UI spacing tweak, asset/notice additions, and a dependency bump for i18next. Changes
Sequence Diagram(s)sequenceDiagram
participant Dev as Developer / PR
participant GH as GitHub
participant ReleaseAction as .github/workflows/release.yml
participant Semantic as semantic-release
participant NewSpec as .github/workflows/new-spec-release.yml
participant Website as Website repo
note right of ReleaseAction #e6f2ff: release workflow triggered on push to branches
Dev->>GH: Push to master/next-spec/next-major-spec (PR merged)
GH->>ReleaseAction: Trigger job
ReleaseAction->>Semantic: Run semantic-release with GH_TOKEN and bot identity
Semantic->>GH: Create GitHub Release & tag
GH-->>NewSpec: Release published event
NewSpec->>NewSpec: Checkout spec + checkout website repo
NewSpec->>NewSpec: Copy spec -> website/docs, remove TOC via remove-toc.js
NewSpec->>NewSpec: Update redirect rules (latest/prerelease logic)
NewSpec->>Website: Commit & push branch + open PR
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Pre-merge checks and finishing touches❌ Failed checks (2 warnings, 1 inconclusive)
✅ Passed checks (2 passed)
✨ Finishing touches🧪 Generate unit tests (beta)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (1)
⏰ Context from checks skipped due to timeout of 180000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
🔇 Additional comments (2)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 24
♻️ Duplicate comments (2)
examples/rpc-server-asyncapi.yml (2)
28-32: Inconsistent AMQP binding configuration (duplicate concern).Same issue as in rpc-client-asyncapi.yml: channel bindings lack
ackproperties that appear in operations (lines 60, 68). Verify AsyncAPI 3.0.0 specification compliance for consistent binding placement.Also applies to: 49-53
30-30: Non-standard AMQP binding syntax:is: queue(duplicate concern).Same issue as in rpc-client-asyncapi.yml. Verify the
is: queuesyntax is valid per AsyncAPI 3.0.0 AMQP binding specification.Also applies to: 51-51
🧹 Nitpick comments (15)
components/layout/GenericLayout.tsx (1)
43-43: Consider using explicit margin classes for clarity.The combination of
m-4andmy-6creates redundancy wheremy-6overrides the vertical margins set bym-4. For better maintainability and clarity, use explicit horizontal and vertical margin classes.Apply this diff to make the intent explicit:
- <AnnouncementHero className={`m-4 text-center my-6 ${hideBanner && 'hidden'}`} small={true} /> + <AnnouncementHero className={`mx-4 my-6 text-center ${hideBanner && 'hidden'}`} small={true} />This achieves the same result (horizontal margins of 1rem, vertical margins of 1.5rem) but makes the spacing intent clearer without relying on override behavior.
examples/operation-security-asyncapi.yml (1)
19-28: Clarify inline security vs. reusable scheme definition.The operation defines OAuth2 inline (lines 19–28) while also declaring an identical scheme in
securitySchemes(lines 109–117). In AsyncAPI 3.0.0, it's cleaner to reference the named scheme fromsecuritySchemesrather than repeating the full configuration inline.Replace the inline security block with a reference to the named scheme:
security: - - type: oauth2 - description: The oauth security descriptions - flows: - clientCredentials: - tokenUrl: 'https://example.com/api/oauth/dialog' - availableScopes: - 'subscribe:auth_revocations': Scope required for authorization revocation topic - scopes: - - 'subscribe:auth_revocations' + - notifications_auth: + - 'subscribe:auth_revocations'(Also ensure the scheme is renamed to
notifications_authas noted in the earlier comment.)examples/slack-rtm-asyncapi.yml (1)
565-577: Loosely typed object definitions may cause schema validation issues.Lines 570 and 605 define
commentas an empty object ({}) without a type or properties specification. This allows any structure to pass validation. If the comment field has a known structure in the Slack RTM API, define it explicitly; otherwise, document this intentional flexibility.If the comment structure is unknown or intentionally flexible, consider adding a
type: objectwithadditionalProperties: truefor clarity:- comment: {} + comment: + type: object + additionalProperties: trueexamples/social-media/comments-service/asyncapi.yaml (1)
6-19: MQTT server configuration is consistent across specs.The Comments Service uses the same
mosquittoserver as the backend spec. Verify this is the correct shared message broker for inter-service communication and consider whether a reference to../common/servers.yaml#/mosquittowould be more maintainable than inline definition.Consider extracting the MQTT server definition to
../common/servers.yamland referencing it like the WebSocket server in the backend spec:- servers: - mosquitto: - host: test.mosquitto.org - protocol: mqtt - tags: - - name: 'env:production' - description: This environment is meant for production use case - - name: 'kind:remote' - description: This server is a remote server. Not exposed by the application - - name: 'visibility:public' - description: This resource is public and available to everyone - bindings: - mqtt: - clientId: comment-service + servers: + mosquitto: + $ref: '../common/servers.yaml#/mosquitto'This would reduce duplication across the social-media example services and make server configuration changes easier to maintain.
examples/rpc-client-asyncapi.yml (2)
14-14: Inconsistent channel address format between queue and rpc_queue.Line 14 uses a parameterized address format (
'{queue}') while line 34 uses a literal address (rpc_queue). While both may be valid, clarify the intent: does the queue channel need to accept dynamic queue names? If so, consider making the rpc_queue similarly parameterizable for consistency, or document why one is parameterized and the other is not.Also applies to: 34-34
24-25: Message payload examples are minimal; consider more realistic test data.Lines 24-25 and 46-48 provide example payloads. While syntactically correct, the examples are simplistic (single-digit numbers). Consider expanding with more realistic examples that demonstrate edge cases (e.g., large numbers, negative numbers for sum operation) to improve documentation clarity.
Also applies to: 46-48
.markdownlint.yaml (1)
1-9: Fix typos in configuration comments.The YAML configuration is valid, but the inline comments contain spelling errors that should be corrected for clarity:
- Line 2: "maeke" → "make"
- Line 5: "investingation" → "investigation"
Apply this diff to fix the typos:
# MD013/line-length - Line length - # We should keep it disabled as this line length limit do not maeke sense really + # We should keep it disabled as this line length limit does not make sense really MD013: false # MD033/no-inline-html - Inline HTML - # We use HTML links in deadings all over the place. Probably this is why links in GitHub do not work, but that requires investingation if we can remove them really + # We use HTML links in headings all over the place. Probably this is why links in GitHub do not work, but that requires investigation if we can remove them really MD033: falseexamples/README.md (1)
9-9: Add hyphen to compound modifier.Line 9 uses "auto completion" which should be hyphenated as "auto-completion" when used as a compound modifier before a noun.
Apply this diff:
- You may notice `asyncapi` in the the name of each example. We recommend doing the same with your AsyncAPI document. This way you enable features like documentation display on node hover, auto completion and validation of your AsyncAPI documents in IDEs like VSCode or IntelliJ IDEA. IDEs integrate with [SchemaStore](https://www.schemastore.org/json/) where AsyncAPI specification JSON Schema files are referenced. Some IDEs do it by default, some, like VSCode require you to install additional extensions, like `YAML` extension. + You may notice `asyncapi` in the name of each example. We recommend doing the same with your AsyncAPI document. This way you enable features like documentation display on node hover, auto-completion and validation of your AsyncAPI documents in IDEs like VSCode or IntelliJ IDEA. IDEs integrate with [SchemaStore](https://www.schemastore.org/json/) where AsyncAPI specification JSON Schema files are referenced. Some IDEs do it by default, some, like VSCode require you to install additional extensions, like `YAML` extension.(Also note: Line 9 contains "in the the" which should be "in the" — only one "the".)
.github/scripts/remove-toc.js (1)
12-24: Add error handling for file operations.File I/O operations can fail (file not found, permission denied, disk full). The script should handle these gracefully.
Wrap file operations in try-catch:
module.exports = (givenSpec) => { const fs = require("fs"); + + try { + const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`, 'utf8'); - const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`); - - const startingIndex = specFile.indexOf(startingLine); + const startingIndex = specFile.indexOf(startingLine); // ... rest of the logic ... + } catch (error) { + console.error(`Error processing ${givenSpec}:`, error.message); + throw error; + } }RELEASE_PROCESS.md (1)
1-50: Excellent comprehensive release process documentation.The structure and workflow descriptions are clear and well-organized. Minor note: consistently capitalize "GitHub" (currently inconsistently capitalized in several places). This is a nice-to-have documentation improvement.
scripts/validation/embedded-examples-validation.js (1)
78-87: Consider collecting all diagnostics before exiting.The current implementation calls
process.exit(1)immediately upon encountering the first error-level diagnostic. This prevents reporting all errors in the document. Consider collecting all error diagnostics and reporting them together for better developer experience.Here's a possible refactor:
if (diagnostics.length > 0) { + let hasError = false; diagnostics.forEach(diagnostic => { const errorMessage = `\x1b[31mError in ${name}: ${diagnostic.message}\x1b[0m`; if (diagnostic.level === 'error') { console.error(errorMessage); - process.exit(1); + hasError = true; } else { console.log(errorMessage); } }); + if (hasError) { + process.exit(1); + } } else {examples/streetlights-kafka-asyncapi.yml (1)
192-199: Consider whether single-value enum is intentional.The
clientIdbinding uses an enum with only one value (my-app-id). If this is the only allowed client ID, consider using a constant string instead. If multiple client IDs are expected, add additional enum values.If a constant is intended:
kafka: bindings: kafka: clientId: - type: string - enum: - - my-app-id + const: my-app-idAlternatively, if this demonstrates the enum pattern for examples, the current structure is acceptable.
scripts/validation/package.json (1)
5-7: Placeholder test script should be implemented or removed.The test script is a placeholder that always exits with an error. Consider either implementing actual tests or removing this script if not needed.
If tests are needed:
"scripts": { - "test": "echo \"Error: no test specified\" && exit 1", + "test": "node --test", "validate:examples": "node embedded-examples-validation.js" },Alternatively, if tests aren't required for this utility:
"scripts": { - "test": "echo \"Error: no test specified\" && exit 1", "validate:examples": "node embedded-examples-validation.js" },examples/anyof-asyncapi.yml (1)
32-36: Add trailing newline to file.The file ends without a newline character after line 36, which violates POSIX standards and can cause issues with some tools.
Add a newline at the end of the file.
.github/workflows/validate-embedded-examples.yml (1)
3-5: Switch topull_requesttrigger—the current implementation is safe but unnecessarily exposes secrets access.The validation script is read-only and doesn't execute untrusted PR code, expose secrets, or modify the repository. However,
pull_request_targetgrants unnecessary access to repository secrets despite the script not requiring them. Usepull_requestinstead to follow the principle of least privilege:on: - pull_request_target: + pull_request: types: [opened, reopened, synchronize, edited, ready_for_review]This change maintains security while eliminating unnecessary elevated permissions.
📜 Review details
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (20)
assets/Gravitee.pngis excluded by!**/*.pngassets/aklivity.pngis excluded by!**/*.pngassets/apideck.pngis excluded by!**/*.pngassets/bump-sh-white-bg.pngis excluded by!**/*.pngassets/bump-sh.svgis excluded by!**/*.svgassets/gemini.svgis excluded by!**/*.svgassets/gitter.pngis excluded by!**/*.pngassets/ibm.pngis excluded by!**/*.pngassets/kong.pngis excluded by!**/*.pngassets/logo.pngis excluded by!**/*.pngassets/mercedes-benz.pngis excluded by!**/*.pngassets/release_process/draft_pr.pngis excluded by!**/*.pngassets/route4me.pngis excluded by!**/*.pngassets/smartbear.pngis excluded by!**/*.pngassets/solace.pngis excluded by!**/*.pngassets/svix.pngis excluded by!**/*.pngassets/tibco.pngis excluded by!**/*.pngpackage-lock.jsonis excluded by!**/package-lock.jsonscripts/converter/package-lock.jsonis excluded by!**/package-lock.jsonscripts/validation/package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (58)
.github/ISSUE_TEMPLATE.md(1 hunks).github/ISSUE_TEMPLATE/bug_report.md(1 hunks).github/ISSUE_TEMPLATE/proposal.md(1 hunks).github/ISSUE_TEMPLATE/question.md(1 hunks).github/ISSUE_TEMPLATE/release.md(1 hunks).github/ISSUE_TEMPLATE/strawman.md(1 hunks).github/PULL_REQUEST_TEMPLATE.md(1 hunks).github/scripts/remove-toc.js(1 hunks).github/workflows/lint.yml(1 hunks).github/workflows/new-spec-release.yml(1 hunks).github/workflows/release.yml(1 hunks).github/workflows/update-spec.yaml(1 hunks).github/workflows/validate-embedded-examples.yml(1 hunks).github/workflows/validate-examples.yml(1 hunks).markdownlint.yaml(1 hunks).releaserc(1 hunks)NOTICE(1 hunks)RELEASE_PROCESS.md(1 hunks)assets/asyncapi.xml(1 hunks)components/layout/GenericLayout.tsx(1 hunks)examples/README.md(1 hunks)examples/adeo-kafka-request-reply-asyncapi.yml(1 hunks)examples/anyof-asyncapi.yml(1 hunks)examples/application-headers-asyncapi.yml(1 hunks)examples/correlation-id-asyncapi.yml(1 hunks)examples/gitter-streaming-asyncapi.yml(1 hunks)examples/kraken-websocket-request-reply-message-filter-in-reply-asyncapi.yml(1 hunks)examples/kraken-websocket-request-reply-multiple-channels-asyncapi.yml(1 hunks)examples/mercure-asyncapi.yml(1 hunks)examples/not-asyncapi.yml(1 hunks)examples/oneof-asyncapi.yml(1 hunks)examples/operation-security-asyncapi.yml(1 hunks)examples/rpc-client-asyncapi.yml(1 hunks)examples/rpc-server-asyncapi.yml(1 hunks)examples/simple-asyncapi.yml(1 hunks)examples/slack-rtm-asyncapi.yml(1 hunks)examples/social-media/backend/asyncapi.yaml(1 hunks)examples/social-media/comments-service/asyncapi.yaml(1 hunks)examples/social-media/common/messages.yaml(1 hunks)examples/social-media/common/parameters.yaml(1 hunks)examples/social-media/common/schemas.yaml(1 hunks)examples/social-media/common/servers.yaml(1 hunks)examples/social-media/frontend/asyncapi.yaml(1 hunks)examples/social-media/notification-service/asyncapi.yaml(1 hunks)examples/social-media/public-api/asyncapi.yaml(1 hunks)examples/social-media/readme.md(1 hunks)examples/streetlights-kafka-asyncapi.yml(1 hunks)examples/streetlights-mqtt-asyncapi.yml(1 hunks)examples/streetlights-operation-security-asyncapi.yml(1 hunks)examples/websocket-gemini-asyncapi.yml(1 hunks)next-env.d.ts(1 hunks)scripts/converter/README.md(1 hunks)scripts/converter/index.js(1 hunks)scripts/converter/package.json(1 hunks)scripts/validation/base-doc-combined.json(1 hunks)scripts/validation/embedded-examples-validation.js(1 hunks)scripts/validation/package.json(1 hunks)scripts/validation/user-create.avsc(1 hunks)
🧰 Additional context used
🧬 Code graph analysis (2)
components/layout/GenericLayout.tsx (1)
components/campaigns/AnnouncementHero.tsx (1)
AnnouncementHero(21-112)
scripts/validation/embedded-examples-validation.js (1)
scripts/converter/index.js (1)
document(15-15)
🪛 actionlint (1.7.8)
.github/workflows/new-spec-release.yml
16-16: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
21-21: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
35-35: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
56-56: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
63-63: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
93-93: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
128-128: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
.github/workflows/lint.yml
14-14: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
.github/workflows/update-spec.yaml
18-18: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
22-22: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
46-46: the runner of "actions/github-script@v6" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
.github/workflows/release.yml
16-16: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
18-18: the runner of "actions/setup-node@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🪛 LanguageTool
.github/ISSUE_TEMPLATE/strawman.md
[grammar] ~1-~1: Hier könnte ein Fehler sein.
Context: --- name: 💭 Strawman (RFC 0) about: See CONTRIBUTING.md title: "" labels: '💭 Strawman (RFC 0)' assignees: '' ---
(QB_NEW_DE)
.github/ISSUE_TEMPLATE/proposal.md
[grammar] ~1-~1: Hier könnte ein Fehler sein.
Context: --- name: 💡 Proposal (RFC 1) about: See CONTRIBUTING.md title: "" labels: '💡 Proposal (RFC 1)' assignees: '' ---
(QB_NEW_DE)
examples/README.md
[grammar] ~9-~9: Use a hyphen to join words.
Context: ...ocumentation display on node hover, auto completion and validation of your AsyncA...
(QB_NEW_EN_HYPHEN)
.github/ISSUE_TEMPLATE/question.md
[grammar] ~1-~1: Hier könnte ein Fehler sein.
Context: --- name: Question about: A question about the spec or processes title: "" labels: '❔ Question' assignees: '' ---
(QB_NEW_DE)
.github/ISSUE_TEMPLATE/release.md
[uncategorized] ~70-~70: The official name of this software platform is spelled with a capital “H”.
Context: ...Write release notes for the releases on Github - [ ] Create releases on Github - [...
(GITHUB)
[uncategorized] ~71-~71: The official name of this software platform is spelled with a capital “H”.
Context: ...ases on Github - [ ] Create releases on Github - [ ] spec - [ ] spec-json-sche...
(GITHUB)
.github/ISSUE_TEMPLATE.md
[grammar] ~1-~1: Hier könnte ein Fehler sein.
Context: --- name: "" about: "" ---
(QB_NEW_DE)
examples/social-media/readme.md
[style] ~20-~20: ‘mixed together’ might be wordy. Consider a shorter alternative.
Context: ...try to describe the following use-cases mixed together: - A public API, and how others may in...
(EN_WORDINESS_PREMIUM_MIXED_TOGETHER)
[grammar] ~24-~24: Use a hyphen to join words.
Context: ...t to ensure we dont focus only on broker centric systems. - Reusability where pos...
(QB_NEW_EN_HYPHEN)
[grammar] ~25-~25: Ensure spelling is correct
Context: ...eusability where possible, to ensure no dublication of definitions
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
RELEASE_PROCESS.md
[style] ~47-~47: The adverb ‘often’ is usually put before the verb ‘release’.
Context: ... day of the month with the release. We release often, so anything that isn't ready can wait ...
(ADVERB_WORD_ORDER)
[style] ~47-~47: As an alternative to the over-used intensifier ‘very’, consider replacing this phrase.
Context: ...vered in as many tools as possible with very good documentation and examples. --- ## Wha...
(EN_WEAK_ADJECTIVE)
[uncategorized] ~53-~53: The official name of this software platform is spelled with a capital “H”.
Context: ...mples. --- ## What? ### Repositories Github repositories that need to be updated at...
(GITHUB)
[uncategorized] ~79-~79: The official name of this software platform is spelled with a capital “H”.
Context: ...ibility over the progress, create a new Github issue in the [spec](https://github.com/...
(GITHUB)
[style] ~192-~192: Consider using a synonym to be more concise.
Context: ...or including in the release. There are lots of ways to do this: - ask for contribution...
(A_LOT_OF)
[uncategorized] ~220-~220: Did you mean the formatting language “Markdown” (= proper noun)?
Context: ...tories). These should: - be written in markdown - include a list of features and signif...
(MARKDOWN_NNP)
[uncategorized] ~222-~222: The official name of this software platform is spelled with a capital “H”.
Context: ...significant changes - include a link to github issues and pull requests where more bac...
(GITHUB)
[uncategorized] ~223-~223: The official name of this software platform is spelled with a capital “H”.
Context: ...ound can be found - include a link to a github diff with the previous release Example...
(GITHUB)
[style] ~264-~264: Consider a more concise word here.
Context: ...al repositories about the pre-releases In order to let code owners of critical repositorie...
(IN_ORDER_TO_PREMIUM)
[uncategorized] ~290-~290: The official name of this software platform is spelled with a capital “H”.
Context: ...ach repository to update the release in Github created by the automation bot, by addin...
(GITHUB)
[uncategorized] ~321-~321: The official name of this software platform is spelled with a capital “H”.
Context: ...asyncapi/ts-nats-template) You can use Github Code Search to find the [list of reposi...
(GITHUB)
[style] ~338-~338: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ... community-driven nature of releases. Feel free to use other communication channels. Make ...
(FEEL_FREE_TO_STYLE_ME)
[style] ~339-~339: Consider using a less common alternative to make your writing sound more unique and professional.
Context: ...ople as possible know about the change. Feel free to contact vendors upfront or other people...
(FEEL_FREE_TO_STYLE_ME)
🔇 Additional comments (51)
examples/slack-rtm-asyncapi.yml (3)
1-10: AI-generated summary is completely unrelated to the actual code.The provided AI summary describes "release infrastructure, GitHub automation workflows, validation systems, and extensive AsyncAPI examples" as if multiple files with semantic-release configurations and workflows are being added. However, this file is a single AsyncAPI spec file with no automation or infrastructure changes. The summary does not accurately reflect the actual code under review.
112-169: Verify all message references in operations are defined in the channels section.The
sendMessagesoperation references approximately 45 message types. Confirm that all these messages have corresponding definitions in the channels/root/messages section (lines 18–111) and in the components/messages section (starting line 225). If any references are missing, the spec will fail validation.
1-10: The review comment is based on a file that is not part of this PR's changes.The file
examples/slack-rtm-asyncapi.ymlexists in the repository but was last modified in a previous PR (#759, commit d78dcea). The current PR (branch: coderabbit_4501) only modifiespackage-lock.json. Since the AsyncAPI file is not being changed in this PR, criticisms about context mismatch between PR objectives and its content are not applicable to this pull request.Likely an incorrect or invalid review comment.
examples/social-media/common/servers.yaml (1)
1-4: LGTM—Valid server definition.The WebSocket server configuration follows AsyncAPI conventions and will be properly reused across the social-media service examples.
examples/social-media/common/messages.yaml (1)
1-16: LGTM—Well-structured message definitions.Message definitions follow AsyncAPI 3.0.0 conventions with consistent naming, clear descriptions, and proper schema references. All referenced payload schemas exist in
./schemas.yaml.examples/social-media/common/schemas.yaml (1)
1-50: LGTM—Well-designed schema composition.The schemas properly use JSON Schema's allOf property for model composition, combining primitive references with inline descriptions. The
additionalProperties: falseconstraint enforces strict validation, which is a good practice. The reuse ofcommentIdanduserIdacross multiple payloads minimizes duplication.examples/social-media/frontend/asyncapi.yaml (1)
1-33: LGTM—Proper AsyncAPI 3.0.0 structure.The specification correctly implements the AsyncAPI 3.0.0 pattern with decoupled channels and operations. Server references are properly resolved, and message contracts are clearly defined through external references to shared definitions.
examples/social-media/notification-service/asyncapi.yaml (1)
1-34: LGTM—Well-configured MQTT service specification.The specification properly defines the Notifications Service with appropriate server tags (production, remote, public visibility), MQTT binding, and a clear receive operation for the
commentLikedchannel.examples/social-media/public-api/asyncapi.yaml (1)
1-35: LGTM—Properly structured public API specification.The specification clearly defines the Public API contract with appropriate server configuration, MQTT bindings, and a descriptive channel operation explaining the publish–subscribe semantics for consumers.
examples/social-media/common/parameters.yaml (1)
1-2: The original review comment is incorrect.AsyncAPI 3.0.0 does not mandate a schema field in Parameter Objects. A Parameter Object itself has no single required property mandated by the core spec. The current definition—with parameter name matching the channel address template and a description present—is structurally valid per specification.
While adding schema information could be a stylistic enhancement for documentation purposes, the review's assertion that it's required by AsyncAPI is inaccurate.
Likely an incorrect or invalid review comment.
examples/social-media/backend/asyncapi.yaml (4)
1-83: Inconsistency detected: PR objectives do not match provided files.The PR objectives describe CSS styling fixes for announcement banners and navbars on the website, but the provided files are AsyncAPI 3.0.0 specifications for a social-media example backend service. This is a significant mismatch between stated PR scope and actual file content.
Could you clarify whether:
- The wrong files were provided for this review?
- These YAML files are part of a larger PR with multiple unrelated changes?
- The PR objectives should have described the addition of AsyncAPI examples instead?
Proceeding with a review of the AsyncAPI files as-is, but this discrepancy should be resolved.
59-83: Verify operation-channel-message mapping is correct.The operations correctly reference channels and messages using
$ref. However, ensure the following for AsyncAPI 3.0.0 compliance:
- Line 65:
receiveCommentLikesends message fromnewLikeCommentchannel ✓- Line 71:
receiveCommentChangesends message fromcommentsCountChangechannel ✓- Line 77:
sendCommentLikeUpdatesends message fromupdateCommentsCountchannel ✓- Line 65, 71, 77, 83: All message refs are properly scoped to their respective channels ✓
Verify with the comments-service spec that the operation directions (send/receive) are consistent and properly paired between services.
21-58: Channel design is clear and well-structured.The four channels represent distinct event flows with appropriate server assignments. However, verify:
commentsCountChangecorrectly uses thecommentIdpath parameter from common definitions- Server routing is correct:
mosquittofor inter-service communication,websiteWebSocketServerfor frontend- Address patterns (e.g.,
comment/{commentId}/changed) match backend routing logic
7-7: All external references are valid and properly resolved.Verification confirms that:
../common/servers.yamlcontains thewebsiteWebSocketServerdefinition../common/messages.yamlcontains all referenced messages:commentLiked,likeComment,commentChanged,updateCommentLikes../common/parameters.yamlcontains thecommentIdparameterAll external file references in the spec resolve correctly with expected definitions.
examples/social-media/comments-service/asyncapi.yaml (1)
1-52: Comments Service spec is well-structured and focused.The Comments Service spec correctly defines a focused subset of the event flow compared to the backend spec. Two channels and two operations represent a simple receive-then-send pattern: service receives comment-liked events and sends back the updated count.
Verify the following:
- Operation
receiveCommentLiked(line 41-46) pairs with the backend'ssendCommentLikedoperation- Operation
sendCommentChange(line 47-52) pairs with the backend'sreceiveCommentChangeoperation- All external message/parameter references in common files are properly defined
examples/kraken-websocket-request-reply-message-filter-in-reply-asyncapi.yml (5)
1-388: Scope mismatch: PR objectives vs. file under review.The PR objectives describe CSS styling fixes for website components (announcement banner, navbar), but the file provided is an AsyncAPI specification example. Verify that this file is indeed part of PR #4501, or clarify which PR this review is for. If this file is intentionally included, please provide updated PR context.
1-19: AsyncAPI metadata and documentation look good.The info section is well-structured with comprehensive API description covering TLS requirements, message encoding, connection limits, and reconnection behavior.
140-162: Message examples and structure look comprehensive.The subscriptionStatus message includes two well-documented examples (success and error cases) that demonstrate different subscription outcomes. Other messages are properly defined with payloads and correlationId mappings.
21-41: All channel message references are properly defined in components.Verification confirms all 8 message references in the channels section (ping, pong, heartbeat, systemStatus, subscriptionStatus, subscribe, unsubscribe, dummyCurrencyInfo) are correctly defined in the components/messages section. No missing or undefined references.
1-388: AsyncAPI specification is valid and ready for use.The file passes all validation checks:
- ✓ YAML syntax is valid
- ✓ AsyncAPI specification is valid
- ✓ No governance issues detected
The specification correctly documents the Kraken WebSockets API with comprehensive channel definitions, operation patterns, and schema components. No issues require addressing.
examples/rpc-server-asyncapi.yml (1)
64-69: Asymmetric message reference in sum operation.The
sumoperation (lines 64-69) does not include an explicitmessagessection referencing#/channels/rpc_queue/messages/sum, unlike the correspondingrequestSumoperation in the client example. While this may be valid in AsyncAPI 3.0.0, verify this is intentional. For consistency with the client example and clarity, consider adding:sum: action: receive channel: $ref: '#/channels/rpc_queue' + messages: + - $ref: '#/channels/rpc_queue/messages/sum'examples/rpc-client-asyncapi.yml (3)
1-72: Unable to retrieve PR metadata (title, description, changed files) to verify the scope mismatch claim in the original review comment. The GitHub CLI did not find an associated PR, and git diff produced no output. Without access to the PR's stated objectives and the full list of files actually modified, I cannot definitively confirm whether the AsyncAPI file is misaligned with the PR's intended scope or whether the original review comment is based on incomplete information.
30-30: Code is correct per AsyncAPI 3.0.0 specification.The
isproperty is a standard AMQP channel binding in AsyncAPI 3.0.0 that declares the channel type as either "queue" or "routingKey", with examples in the specification showingis: queue. No changes needed.Likely an incorrect or invalid review comment.
28-32: Review comment is incorrect and based on a misunderstanding of AsyncAPI 3.0.0 specification.The AMQP "ack" property belongs in the AMQP operation binding (operation.bindings.amqp.ack), specified on an Operation—not in channel or message bindings. The file's current structure is correct: channel bindings (lines 28-32, 49-53) appropriately exclude
ack, while operation bindings (lines 63, 72) correctly placeackconfiguration. No changes are required.Likely an incorrect or invalid review comment.
scripts/validation/user-create.avsc (1)
1-15: Avro schema structure looks good.Properly formatted record with appropriate namespace and field definitions. No issues identified.
NOTICE (1)
1-2: Standard copyright notice.Proper attribution to The Linux Foundation for the AsyncAPI Initiative.
scripts/converter/README.md (1)
1-1: Clear documentation for the converter script.Purpose is clearly stated. No issues identified.
.github/ISSUE_TEMPLATE/strawman.md (1)
1-23: RFC 0 strawman template is well-structured.Template frontmatter and guidance sections are properly formatted. Clearly directs users to contributing guidelines and relevant repositories for different types of requests.
.github/PULL_REQUEST_TEMPLATE.md (1)
1-18: The structure is valid—this follows standard GitHub PR template conventions.The first
---...---block (lines 1–3) is Jekyll YAML frontmatter, which is valid and commonly used in GitHub templates. The second---(line 5) is not a frontmatter block; it's a markdown horizontal rule separator, which is intentional. This pattern—frontmatter followed by a visual separator—is a standard, deliberate design in GitHub PR templates and requires no correction.Likely an incorrect or invalid review comment.
next-env.d.ts (1)
1-6: Standard Next.js declaration file - no issues.This is a correctly formatted Next.js TypeScript declaration file. The ambient references and warning comment are appropriate.
However, this file's presence in a PR described as fixing CSS spacing issues is questionable. Verify this is the intended change.
assets/asyncapi.xml (1)
1-1: Valid XML structure for diagram library.The XML structure is valid. This appears to be an mxGraph/draw.io library resource with base64-encoded diagram components.
Note: The presence of this asset file in a PR described as fixing CSS spacing is unexpected. Verify this is intentional.
examples/not-asyncapi.yml (1)
1-29: Valid AsyncAPI 3.0.0 document demonstrating JSON Schema "not" constraint.The document structure is correct and properly demonstrates the
notkeyword. The schema will accept any type for thekeyproperty except integers.All references via
$refare properly formed and point to valid internal component paths..github/ISSUE_TEMPLATE/proposal.md (1)
1-23: Issue template structure is correct.The YAML front matter and guidance are properly formatted.
Same concern as
question.md: links referenceasyncapi/specrepository (lines 17, 21). Verify these match the intended repository context..github/ISSUE_TEMPLATE.md (1)
1-20: Default issue template structure is correct.The empty
nameandaboutfields suggest this is a fallback template, which is valid.Same repository path reference concern applies: verify links to
asyncapi/spec(lines 14, 18) match the intended repository..github/ISSUE_TEMPLATE/bug_report.md (1)
1-45: Comprehensive bug report template.The template is well-structured with clear sections and helpful placeholders specific to AsyncAPI document validation workflows.
Repository path references on lines 17 and 21 point to
asyncapi/spec. Verify these match the intended repository context..github/ISSUE_TEMPLATE/question.md (1)
1-23: All repository references are contextually correct—no changes needed.The template is specifically for "a question about the spec or processes," not general website issues. The links appropriately direct users to different repositories based on their issue type:
- Line 17 (editing mistakes) → asyncapi/spec ✓ (spec source files live there)
- Line 19 (documentation improvements) → asyncapi/website ✓ (website-specific)
- Line 21 (feature requests in spec context) → asyncapi/spec/CONTRIBUTING.md ✓ (spec contribution guidelines)
The template's design is intentional and correct.
scripts/converter/package.json (1)
1-12: Critical: File does not match PR objectives.This PR claims to fix CSS spacing issues in the announcement banner and navbar (#4495), but this file is a Node.js package manifest for an AsyncAPI converter tool. There is no connection to CSS styling, banner components, or navbar layout.
Please verify:
- Are these the correct files for PR #4501?
- Is the PR description/objective incorrect?
- Has there been a mix-up in the review process?
examples/application-headers-asyncapi.yml (1)
1-86: Critical: File does not match PR objectives.This AsyncAPI 3.0.0 specification file for application headers testing has no connection to the stated PR objective of fixing CSS spacing in the announcement banner and navbar.
examples/simple-asyncapi.yml (1)
1-31: Critical: File does not match PR objectives.This AsyncAPI specification file is unrelated to the CSS spacing fixes for announcement banner and navbar described in the PR objectives.
examples/oneof-asyncapi.yml (1)
1-57: Critical: File does not match PR objectives.This AsyncAPI oneOf example specification has no connection to CSS styling, announcement banners, or navbar components referenced in the PR description.
scripts/converter/index.js (1)
1-57: Critical: File does not match PR objectives.This is a Node.js converter script for AsyncAPI specifications. It has no relation to the CSS spacing adjustments for announcement banner and navbar described in PR #4501's objectives.
scripts/validation/base-doc-combined.json (1)
1-711: Critical: File does not match PR objectives.This base AsyncAPI validation document is completely unrelated to the CSS spacing fixes for the announcement banner and navbar that this PR claims to address.
examples/gitter-streaming-asyncapi.yml (1)
1-178: Critical: File does not match PR objectives.This Gitter Streaming API specification is unrelated to CSS spacing adjustments for announcement banner and navbar mentioned in the PR objectives.
examples/streetlights-mqtt-asyncapi.yml (1)
1-253: Critical: File does not match PR objectives.This Streetlights MQTT API specification has no connection to the CSS spacing fixes for announcement banner and navbar that PR #4501 claims to implement.
examples/mercure-asyncapi.yml (1)
1-58: LGTM!Well-structured AsyncAPI 3.0.0 specification example for Mercure Hub. The schema is valid with proper channel definitions, message types, and operational semantics.
examples/kraken-websocket-request-reply-multiple-channels-asyncapi.yml (1)
1-393: LGTM!Comprehensive and well-structured AsyncAPI 3.0.0 specification for Kraken WebSocket API. The request-reply patterns are properly implemented, message definitions include detailed schema constraints, and the specification includes helpful examples. Excellent documentation.
examples/adeo-kafka-request-reply-asyncapi.yml (2)
1-295: Major inconsistency: This file doesn't match the PR objectives.According to the PR objectives, this PR is supposed to fix CSS spacing issues in the announcement banner and navbar (#4495). However, this file is an AsyncAPI specification example for Kafka request-reply patterns, which is completely unrelated to CSS fixes.
This suggests either:
- The wrong files were attached to this review
- The PR objectives are incorrect
- This review is for a different PR
Please verify that the correct files are being reviewed for PR #4501.
174-174: External schema URLs are accessible.Verification confirms both referenced Avro schemas return HTTP 200 responses and are currently available:
CostingRequestPayload.avsc: 200 ✓CostingResponsePayload.avsc: 200 ✓The example specification can safely reference these URLs. Long-term maintenance depends on AsyncAPI's stewardship of their case studies resources, which is outside the scope of this codebase.
scripts/validation/embedded-examples-validation.js (1)
1-117: Major inconsistency: This file doesn't match the PR objectives.According to the PR objectives, this PR is supposed to fix CSS spacing issues in the announcement banner and navbar (#4495). However, this file is a validation script for AsyncAPI examples, which is completely unrelated to CSS fixes.
This suggests either:
- The wrong files were attached to this review
- The PR objectives are incorrect
- This review is for a different PR
Please verify that the correct files are being reviewed for PR #4501.
.releaserc (1)
1-13: LGTM!The semantic-release configuration is well-structured with appropriate branch setup for spec releases. The use of conventional commits for both analysis and release notes generation, combined with prerelease branches for spec work, follows best practices.
examples/correlation-id-asyncapi.yml (1)
99-101: I'll verify the actual file content and check the AsyncAPI specifications for MQTT correlation IDs.<!-- [scratchpad_update]
[observations]
- Found AsyncAPI official spec file at master branch shows correlation ID with $ref to #/components/correlationIds/sentAtCorrelator
- Official spec shows location: "$message.header#/correlationId" is a common pattern (from spec docs)
- MQTT bindings documentation exists but doesn't define header structure like IBM MQ
- AsyncAPI is protocol-agnostic; can use custom headers for MQTT
[analysis]
- The AsyncAPI specification allows protocol-agnostic correlation ID locations using runtime expressions like $message.header#/correlationId
- The location $message.header#/MQMD/CorrelId appears to be attempting IBM MQ-specific syntax
- MQTT doesn't have standardized MQMD headers like IBM MQ does
- Need to check actual file to see exact content at line 100 and 13
[pending]
- Verify file content, particularly line 13 (protocol) and lines 99-101 (correlation ID)
- Check if MQMD syntax is valid/acceptable in AsyncAPI for MQTT
[actions]
- Read correlation-id-asyncapi.yml file
| - [ ] Write release notes for the releases on Github | ||
| - [ ] Create releases on Github |
There was a problem hiding this comment.
Fix capitalization: "Github" → "GitHub".
The official name uses a capital "H": "GitHub" not "Github".
Apply this diff:
-- [ ] Write release notes for the releases on Github
-- [ ] Create releases on Github
+- [ ] Write release notes for the releases on GitHub
+- [ ] Create releases on GitHub
- [ ] spec
- [ ] spec-json-schemas
- [ ] parser-js📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - [ ] Write release notes for the releases on Github | |
| - [ ] Create releases on Github | |
| - [ ] Write release notes for the releases on GitHub | |
| - [ ] Create releases on GitHub |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~70-~70: The official name of this software platform is spelled with a capital “H”.
Context: ...Write release notes for the releases on Github - [ ] Create releases on Github - [...
(GITHUB)
[uncategorized] ~71-~71: The official name of this software platform is spelled with a capital “H”.
Context: ...ases on Github - [ ] Create releases on Github - [ ] spec - [ ] spec-json-sche...
(GITHUB)
🤖 Prompt for AI Agents
In .github/ISSUE_TEMPLATE/release.md around lines 70 to 71, the occurrences of
"Github" should be changed to the correctly capitalized "GitHub"; update both
checklist items ("Write release notes for the releases on GitHub" and "Create
releases on GitHub") so the brand name uses a capital H.
| module.exports = (givenSpec) => { | ||
| const fs = require("fs"); | ||
|
|
||
| const startingLine = "## Table of Contents\n"; | ||
| const endingLine = "<!-- /TOC -->\n"; | ||
|
|
||
| const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`); |
There was a problem hiding this comment.
Security: Add input validation to prevent path traversal.
The givenSpec parameter is not validated. A malicious input like "../../../sensitive-file" could access files outside the intended directory.
Add validation before using the parameter:
module.exports = (givenSpec) => {
const fs = require("fs");
+
+ // Validate givenSpec to prevent path traversal
+ if (!givenSpec || givenSpec.includes('..') || givenSpec.includes('/') || givenSpec.includes('\\')) {
+ throw new Error('Invalid specification name');
+ }
const startingLine = "## Table of Contents\n";🤖 Prompt for AI Agents
.github/scripts/remove-toc.js around lines 6 to 12: the givenSpec parameter is
used directly to build a file path enabling path traversal; validate and
sanitize it before use by (1) disallowing any path separators or traversal
tokens (no "../", no "/" or "\"), (2) optionally restrict to a safe whitelist or
a strict regex (e.g. only letters, numbers, hyphen, underscore), (3) build the
target path using path.join against the known base directory and call
path.resolve on the result and the base directory, then verify the resolved path
starts with the base directory; if validation fails, throw a clear error and do
not read the file.
| const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`); | ||
|
|
||
| const startingIndex = specFile.indexOf(startingLine); | ||
| const endingIndex = specFile.indexOf(endingLine); | ||
|
|
||
| if (startingIndex === -1 || endingIndex === -1) { | ||
| console.log("TOC not found"); | ||
| return; | ||
| } | ||
| const firstHalf = specFile.slice(0, startingIndex); | ||
| const secondHalf = specFile.slice(endingIndex + endingLine.length); | ||
| const specWithoutToc = `${firstHalf}${secondHalf}`; | ||
| fs.writeFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`, specWithoutToc); |
There was a problem hiding this comment.
Critical: Missing encoding causes Buffer handling issues.
fs.readFileSync without an encoding returns a Buffer, not a string. The indexOf and slice operations will work but may produce unexpected results. Line 23 concatenates Buffer slices with a template string, which could fail or produce incorrect output.
Apply this diff to fix the encoding issue:
- const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`);
+ const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`, 'utf8');📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`); | |
| const startingIndex = specFile.indexOf(startingLine); | |
| const endingIndex = specFile.indexOf(endingLine); | |
| if (startingIndex === -1 || endingIndex === -1) { | |
| console.log("TOC not found"); | |
| return; | |
| } | |
| const firstHalf = specFile.slice(0, startingIndex); | |
| const secondHalf = specFile.slice(endingIndex + endingLine.length); | |
| const specWithoutToc = `${firstHalf}${secondHalf}`; | |
| fs.writeFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`, specWithoutToc); | |
| const specFile = fs.readFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`, 'utf8'); | |
| const startingIndex = specFile.indexOf(startingLine); | |
| const endingIndex = specFile.indexOf(endingLine); | |
| if (startingIndex === -1 || endingIndex === -1) { | |
| console.log("TOC not found"); | |
| return; | |
| } | |
| const firstHalf = specFile.slice(0, startingIndex); | |
| const secondHalf = specFile.slice(endingIndex + endingLine.length); | |
| const specWithoutToc = `${firstHalf}${secondHalf}`; | |
| fs.writeFileSync(`./website/pages/docs/reference/specification/${givenSpec}.md`, specWithoutToc); |
🤖 Prompt for AI Agents
In .github/scripts/remove-toc.js around lines 12 to 24, the file is read without
an encoding which returns a Buffer and can make indexOf/slice/concatenation
behave incorrectly; change the read to return a string (e.g.,
fs.readFileSync(path, 'utf8') or call .toString('utf8') on the buffer) so
startingIndex/endingIndex operate on strings, then ensure fs.writeFileSync
writes the resulting string with encoding (or pass 'utf8') so the concatenated
specWithoutToc is written correctly.
| runs-on: ubuntu-latest | ||
| steps: | ||
| - name: Checkout repository | ||
| uses: actions/checkout@v3 |
There was a problem hiding this comment.
Update deprecated GitHub Actions checkout version to v4.
The actions/checkout@v3 action uses node16 under the hood, which is deprecated by GitHub. Upgrade to v4 to use the current node20 runtime for improved security and future compatibility.
Apply this diff:
- name: Checkout repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v4📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| uses: actions/checkout@v3 | |
| - name: Checkout repository | |
| uses: actions/checkout@v4 |
🧰 Tools
🪛 actionlint (1.7.8)
14-14: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
.github/workflows/lint.yml around line 14: the workflow uses the deprecated
actions/checkout@v3 which runs on Node 16; update the step to use
actions/checkout@v4 by replacing the v3 reference with v4 so the action runs on
the current Node 20 runtime for improved security and compatibility.
| GITHUB_TOKEN: ${{ secrets.GH_TOKEN }} | ||
| steps: | ||
| - name: Checkout Current repository | ||
| uses: actions/checkout@v3 |
There was a problem hiding this comment.
Update GitHub Actions to latest versions across the workflow.
The workflow uses outdated GitHub Actions in multiple places: actions/checkout@v3 (lines 16, 21) and actions/github-script@v6 (lines 35, 56, 63, 93, 128). Latest checkout is v5, and github-script v8 provides Node 24 runtime. Update all occurrences to ensure runner compatibility.
Apply this diff pattern to all occurrences:
- name: Checkout Current repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v5
with:
path: spec
ref: ${{ github.event.release.target_commitish }}
- name: Checkout Another repository
- uses: actions/checkout@v3
+ uses: actions/checkout@v5
with:
repository: asyncapi/website
path: website
token: ${{ env.GITHUB_TOKEN }}
- name: Check for previous spec file and remove it
uses: actions/github-script@v6
+ uses: actions/github-script@v8(Continue applying same pattern to all remaining actions/github-script@v6 → @v8 upgrades on lines 56, 63, 93, 128)
Also applies to: 21-21, 35-35, 56-56, 63-63, 93-93, 128-128
🧰 Tools
🪛 actionlint (1.7.8)
16-16: the runner of "actions/checkout@v3" action is too old to run on GitHub Actions. update the action's version to fix this issue
(action)
🤖 Prompt for AI Agents
In .github/workflows/new-spec-release.yml around line 16 (and also lines 21, 35,
56, 63, 93, 128), the workflow references outdated actions; update all
occurrences of actions/checkout@v3 to actions/checkout@v5 and
actions/github-script@v6 to actions/github-script@v8 to ensure runner and Node
compatibility. Edit each matching line to use the new versions, keeping any
existing inputs/arguments unchanged, then run a quick workflow lint or dry run
to verify the syntax and compatibility.
| Fig.1 - Mermaid diagram for the system, partly generated using <a href="https://github.com/asyncapi/cupid">Cupid</a>. | ||
| </p> | ||
|
|
||
| This ensures that we try to describe the following use-cases mixed together: |
There was a problem hiding this comment.
Fix typos and grammar issues in documentation.
Static analysis identified three issues that should be corrected:
- Line 20: "mixed together" is redundant; consider removing or rephrasing.
- Line 24: "dont" is missing an apostrophe and "broker centric" should be hyphenated.
- Line 25: "dublication" is misspelled; should be "duplication".
Apply this diff to fix:
-This ensures that we try to describe the following use-cases mixed together:
+This ensures that we try to describe the following use-cases together:
- - A WebSocket server and client to ensure we dont focus only on broker centric systems.
- - Reusability where possible, to ensure no dublication of definitions
+ - A WebSocket server and client to ensure we don't focus only on broker-centric systems.
+ - Reusability where possible, to ensure no duplication of definitionsAlso applies to: 24-24, 25-25
🧰 Tools
🪛 LanguageTool
[style] ~20-~20: ‘mixed together’ might be wordy. Consider a shorter alternative.
Context: ...try to describe the following use-cases mixed together: - A public API, and how others may in...
(EN_WORDINESS_PREMIUM_MIXED_TOGETHER)
🤖 Prompt for AI Agents
In examples/social-media/readme.md around lines 20, 24 and 25, fix several typos
and grammar: remove the redundant phrase "mixed together" on line 20 or rephrase
the sentence to avoid redundancy; on line 24 change "dont" to "don't" and
hyphenate "broker centric" to "broker-centric"; on line 25 correct the spelling
"dublication" to "duplication". Ensure punctuation and spacing remain consistent
after edits.
| turnOn: | ||
| action: send | ||
| channel: | ||
| $ref: '#/channels/lightTurnOn' | ||
| security: | ||
| - type: oauth2 | ||
| description: The oauth security descriptions | ||
| flows: | ||
| clientCredentials: | ||
| tokenUrl: 'https://example.com/api/oauth/dialog' | ||
| availableScopes: | ||
| 'streetlights:read': Scope required for subscribing to channel | ||
| 'streetlights:write': Scope required for publishing to channel | ||
| scopes: | ||
| - 'streetlights:read' | ||
| traits: | ||
| - $ref: '#/components/operationTraits/kafka' | ||
| messages: | ||
| - $ref: '#/channels/lightTurnOn/messages/turnOn' |
There was a problem hiding this comment.
🛠️ Refactor suggestion | 🟠 Major
Eliminate duplicated OAuth2 security definitions.
The OAuth2 configuration (lines 92-101) is duplicated across multiple operations (turnOn, turnOff at lines 110-120, dimLight at lines 129-139) and the server definition (lines 22-32). The component streetlights_auth (lines 212-220) exists but is never used.
Apply this pattern to all operations to reference the component:
turnOn:
action: send
channel:
$ref: '#/channels/lightTurnOn'
security:
- - type: oauth2
- description: The oauth security descriptions
- flows:
- clientCredentials:
- tokenUrl: 'https://example.com/api/oauth/dialog'
- availableScopes:
- 'streetlights:read': Scope required for subscribing to channel
- 'streetlights:write': Scope required for publishing to channel
- scopes:
- - 'streetlights:read'
+ - $ref: '#/components/securitySchemes/streetlights_auth'
+ scopes:
+ - 'streetlights:read'
traits:
- $ref: '#/components/operationTraits/kafka'Apply the same refactor to turnOff (lines 106-124) and dimLight (lines 125-143).
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In examples/streetlights-operation-security-asyncapi.yml around lines 87-105
(and similarly for turnOff at ~106-124 and dimLight at ~125-143), remove the
duplicated inline OAuth2 security object and replace it with a security
requirement that references the existing
components.securitySchemes.streetlights_auth; specifically, delete the
"security: - type: oauth2 ..." block under each operation and instead add a
security entry like "- streetlights_auth: ['streetlights:write']" (or the
appropriate scopes per operation). Do the same refactor for the server-level
duplicated OAuth2 definition by pointing to the component scheme instead of
repeating the full flows, and ensure
components.securitySchemes.streetlights_auth remains as the single source of
truth.
| side: | ||
| type: string | ||
| enum: | ||
| - bid | ||
| - side | ||
| reason: |
There was a problem hiding this comment.
🧩 Analysis chain
Verify enum value for side property.
Line 279 lists 'side' as an enum value in the side property, which appears to be incorrect. The enum likely should be 'ask' instead of 'side', as the property is named side and should enumerate values like bid and ask, not the property name itself.
Verify this is intentional or apply the fix:
side:
type: string
enum:
- bid
- - side
+ - askI need to examine the actual file to verify the enum value. Let me check the content and context of the file.
🏁 Script executed:
#!/bin/bash
# Examine the file content around the flagged lines
echo "=== Lines 270-285 of websocket-gemini-asyncapi.yml ==="
sed -n '270,285p' examples/websocket-gemini-asyncapi.yml
echo ""
echo "=== Search for other 'side' property definitions ==="
rg -n "side:" examples/websocket-gemini-asyncapi.yml -A 5
echo ""
echo "=== Check for any documentation or comments about side property ==="
rg -n -B 5 -A 5 "bid|ask" examples/websocket-gemini-asyncapi.yml | head -50Length of output: 2414
Fix enum value for side property.
Line 279 contains a typo: the side property enum lists 'side' instead of 'ask'. In a financial trading context (Gemini WebSocket API), the side property should enumerate the two sides of an order book: bid and ask. The current value prevents valid ask orders from being properly validated against this schema.
side:
type: string
enum:
- bid
- - side
+ - ask📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| side: | |
| type: string | |
| enum: | |
| - bid | |
| - side | |
| reason: | |
| side: | |
| type: string | |
| enum: | |
| - bid | |
| - ask | |
| reason: |
🤖 Prompt for AI Agents
In examples/websocket-gemini-asyncapi.yml around lines 275 to 280, the enum for
the side property is incorrect (contains 'side' instead of 'ask'); update the
enum values to ["bid", "ask"] on line 279 so the schema correctly validates
order sides; keep formatting consistent with surrounding YAML and run a quick
schema lint to verify no other enum typos remain.
| function applyUpdates(updates, baseDoc) { | ||
| updates.forEach(update => { | ||
| try { | ||
| // Handle root document case | ||
| if (update.json_pointer === '') { | ||
| baseDoc = mergePatch.apply(baseDoc, update.example); | ||
| return; | ||
| } | ||
|
|
||
| // For non-root cases, use jsonpointer to get and set the correct location | ||
| const targetObject = jsonpointer.get(baseDoc, update.json_pointer); | ||
| const updatedObject = mergePatch.apply(targetObject || {}, update.example); | ||
| jsonpointer.set(baseDoc, update.json_pointer, updatedObject); | ||
|
|
||
| } catch (e) { | ||
| console.error(`\nError processing update for '${update.name}' at path '${update.json_pointer}'`, e); | ||
| process.exit(1); | ||
| } | ||
| }); | ||
| return baseDoc; | ||
| } |
There was a problem hiding this comment.
Fix baseDoc mutation bug in root pointer case.
When json_pointer is empty (line 55), the function reassigns baseDoc locally and returns immediately. However, this reassignment doesn't propagate back to the caller because JavaScript passes object references by value. The modified baseDoc is lost.
Apply this diff to fix the issue by restructuring the function to always return the updated document:
-function applyUpdates(updates, baseDoc) {
+function applyUpdates(updates, baseDocOriginal) {
+ let baseDoc = baseDocOriginal;
updates.forEach(update => {
try {
// Handle root document case
if (update.json_pointer === '') {
baseDoc = mergePatch.apply(baseDoc, update.example);
- return;
}
-
- // For non-root cases, use jsonpointer to get and set the correct location
- const targetObject = jsonpointer.get(baseDoc, update.json_pointer);
- const updatedObject = mergePatch.apply(targetObject || {}, update.example);
- jsonpointer.set(baseDoc, update.json_pointer, updatedObject);
-
+ else {
+ // For non-root cases, use jsonpointer to get and set the correct location
+ const targetObject = jsonpointer.get(baseDoc, update.json_pointer);
+ const updatedObject = mergePatch.apply(targetObject || {}, update.example);
+ jsonpointer.set(baseDoc, update.json_pointer, updatedObject);
+ }
} catch (e) {
console.error(`\nError processing update for '${update.name}' at path '${update.json_pointer}'`, e);
process.exit(1);
}
});
return baseDoc;
}🤖 Prompt for AI Agents
In scripts/validation/embedded-examples-validation.js around lines 51-71, the
root-pointer branch reassigns baseDoc inside a forEach callback and returns from
the callback, causing the updated document to be lost to the caller; change the
loop to a for...of (or otherwise avoid the callback-return), remove the early
return, and assign baseDoc = mergePatch.apply(baseDoc, update.example) for the
'' json_pointer case, then continue to the next update; keep the non-root logic
the same (compute updatedObject and jsonpointer.set) and ensure the function
returns the final baseDoc at the end.
| const validationPromises = combinedData.map(async (item) => { | ||
| const updatedDocument = applyUpdates([item], baseDoc); | ||
|
|
||
| await validateParser(updatedDocument, `${item.name}-${item.format}-format`); | ||
| }); |
There was a problem hiding this comment.
Consider deep cloning baseDoc for each validation.
Each validation reuses the same baseDoc object reference. If applyUpdates mutates the base document (as it does for non-root pointers), subsequent validations may be affected by previous patches. Consider cloning baseDoc for each iteration to ensure isolation.
Apply this diff:
const validationPromises = combinedData.map(async (item) => {
- const updatedDocument = applyUpdates([item], baseDoc);
+ const updatedDocument = applyUpdates([item], JSON.parse(JSON.stringify(baseDoc)));
await validateParser(updatedDocument, `${item.name}-${item.format}-format`);
});🤖 Prompt for AI Agents
In scripts/validation/embedded-examples-validation.js around lines 102 to 106,
each iteration currently passes the same baseDoc reference into applyUpdates
which can cause cross-test contamination if applyUpdates mutates the document;
clone baseDoc per-iteration (e.g., const docClone = structuredClone(baseDoc) or
JSON.parse(JSON.stringify(baseDoc)) or _.cloneDeep(baseDoc) depending on
availability) and pass that clone into applyUpdates so each validation runs
against an isolated copy before calling validateParser.
0a74f91 to
7847698
Compare
atharva038
force-pushed
the
fix/css-styling
branch
from
357eb11 to
8b3dab3
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #4501 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 22 22
Lines 778 778
Branches 144 144
=========================================
Hits 778 778 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@atharva038 751 commits, 80 files changed. Are you familiar with git and how to work with it? Have you checked our Contribution Guidelines? All the changes above the red line are irrelevant: 
|
43 participants
Description
This pull request improves the spacing and alignment of the announcement banner and navbar on the website. Previously, the elements appeared cramped and inconsistent across different screen sizes.
The changes include:
Added padding and margin adjustments to the announcement banner for better readability.
Improved spacing in the navbar to make navigation items evenly distributed.
Related issue(s)
Resolves #4495Summary by CodeRabbit
New Features
Documentation
Chores
Style