Skip to content

feat: update SNS Bindings#5134

Open
glowcloud wants to merge 9 commits intomainfrom
feat/swg-18320-update-sns-bindings
Open

feat: update SNS Bindings#5134
glowcloud wants to merge 9 commits intomainfrom
feat/swg-18320-update-sns-bindings

Conversation

@glowcloud
Copy link
Copy Markdown
Contributor

This PR updates SNS Bindings to version 0.2.0 and 1.0.0, including adding new fields in AsyncAPI 2 namespace and restricting validation for 0.1.0 and 0.2.0 to AsyncAPI 2.x, and 1.0.0 to AsyncAPI 3.x.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@glowcloud glowcloud self-assigned this Mar 13, 2026
glowcloud and others added 2 commits March 13, 2026 14:26
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
marker: 'value',
target: 'bindingVersion',
data: {},
targetSpecs: [...AsyncAPI2, ...AsyncAPI3],
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need input here - should we only check if it's a string or make it specific for each spec, so that AsyncAPI 2 allows only 0.1.0 and 0.2.0 while AsyncAPI 3 allows only 1.0.0, and we get an error from validation? This is something that the AsyncAPI parser does, at least for some bindings:

Image

Currently if we are on AsyncAPI 3 and specify version 0.1.0, then we don't get an error but we also don't get any validation or completion for the fields.

Negative here could be if another version of the binding is added and we would need to update the allowed fields BUT in that case the version-specific validation and completion would also not work 🤔 Example of missing updating this rule is actually also visible with AsyncAPI parser:

Image

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Currently, we don't check anywhere for the version-specific string, imo. This is an issue that should be handled by the parser team since they already do checks for some bindings

@glowcloud glowcloud marked this pull request as ready for review March 13, 2026 14:09
@glowcloud glowcloud changed the title feat(ls): update SNS Bindings feat: update SNS Bindings Mar 13, 2026
documentation: {
kind: 'markdown',
value:
"[identifier](https://github.com/asyncapi/bindings/blob/master/sns/2.x.x/README.md#identifier)\n\\\n\\\n**Optional.** Often we can assume that the SNS Topic is the channel name-we provide this field in case the you need to supply the ARN, or the Topic name is not the channel name in the AsyncAPI document.\n\nField Name | Type | Description\n---|:---:|---\n`url` | string | **Optional.** The endpoint is a URL\n`email` | string | **Optional.** The endpoint is an email address\n`phone` | string | **Optional.** The endpoint is a phone number\n`arn` | string | **Optional.** The target is an ARN. For example, for SQS, the identifier may be an ARN, which will be of the form: \"arn:aws:sqs:{region}:{account-id}:{queueName}\"\n`name` | string | **Optional.** The endpoint is identified by a name, which corresponds to an identifying field called 'name' of a binding for that protocol on the Operation Object. For example, if the protocol is 'sqs' then the name refers to the name field sqs binding. We don't use $ref because we are referring, not including.",
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in case the you need
we could create a PR to fix this typo in bindings repo 🤔

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed it for us, will raise a PR there later on.

glowcloud and others added 4 commits March 16, 2026 13:46
Co-authored-by: robert-hebel-sb <robert.hebel@smartbear.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants