Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Way to precisely ignore built-in validator under certain conditions #2368

Open
Baccata opened this issue Aug 12, 2024 · 2 comments
Open

Way to precisely ignore built-in validator under certain conditions #2368

Baccata opened this issue Aug 12, 2024 · 2 comments
Labels
feature-request A feature should be added or improved.

Comments

@Baccata
Copy link

Baccata commented Aug 12, 2024

I'm currently in the process of designing some new semantics for some protocols we have a $work that utilise the standard http bindings.

In particular, these semantics would allow to accommodate existing situations in our org where http endpoints have polymorphic outputs that may issue different status codes / payloads. Supporting this usecase create a valid situation for http-bindings to be used outside of a shape that's used directly as an output of an operation. Conceptually speaking, it's gonna look roughly like this :

operation Foo {
  output := {
     @polymorphicResponse
     response: MyResponse      
  }
}

union MyResponse {
   @httpAltCode(201)
   created: Created
   @httpAltCode(200)
   ok: Ok
}

structure Created {
   @httpHeader("X-Something")
   someHeader: String
   something: String
}

structure Ok {
   @httpHeader("X-Other")
   someOtherHeader: String
   someOtherThing
}

Now the thing is that this doesn't play too well with the HttpBindingTraitIgnoredValidator, as this makes use of the http binding traits in a context that is not taken care of by the official tooling. However I don't want to ignore this validator globally because it's valuable overall.

Is there a way I could tell smithy to silence the validator when binding traits are used in the pattern I've examplified above ?

@mtdowling
Copy link
Member

Hm... Suppressions are the tool for this, but there isn't a built-in way to automatically suppress based on these kinds of unique combinations. You could use the suppress trait on each offending member, though that's tedious. Mixins + suppressions don't help here since these events are emitted on members and members are going to vary. You could suppress these per/namespace using a namespace suppression, though this does require your consumers to wire it up themselves. We could potentially add a selector to metadata based suppressions.

@Baccata
Copy link
Author

Baccata commented Aug 13, 2024

We could potentially add a selector to metadata based suppressions.

If that's a possibility, it would be great 👍

@JordonPhillips JordonPhillips added the feature-request A feature should be added or improved. label Aug 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved.
Projects
None yet
Development

No branches or pull requests

3 participants