Codegen: Generate attributes on endpoints for any specification extensions defined on path or operation objects

[hughsimpson]

The OpenApi spec permits defining Specification Extensions on a large number of components. Not all of those have any kind of obvious mapping into the tapir model; however it feels natural to map extensions on path and operation definitions into .attribute declarations on generated endpoints, thus making this metadata accessible at runtime for $variousSundryPurposes

For context, this would enable me to implement some specific authorization guards cleanly at the implementation layer without having to hack around with tags. I don't think tapir would currently emit any specification extensions when generating the openapi from an endpoint with attributes, so I guess there's a break in idempotency there? But since we currently ignore extensions anyway I don't consider that a new issue and think this should be ok... Happy to engage in alternatives to solve the same problem! But I do think this is the most sensible route

[kciesielski]

Thank you. Technically this should work, but I'm a bit concerned about using AttributeKey[String] for each property. AttributeKey is meant to represent an unique type, and the internal typeName field normally represents its fully qualified name. For extensions, we could have unique value classes like case class XSomeExtensionProperty(value: String) extends AnyVal (or Long, or Map etc.) instead of an AttributeKey[String]("x-some-extension-property"). Wdyt @adamw?

[adamw]

Maybe we could generate a single typed attribute SpecificationExtensions, which would also allow looking up the values in a type-safe way?

[hughsimpson]

Thanks for the comments. The type of the key should've been the right type for the value as specified (rather than always being String), but it did permit multiple types for the same attribute which I guess is wrong. I'll have a fiddle around with this.

[hughsimpson]

I've pushed up a change that I think would be more in line with how attributes are designed (although see other comment - I need to improve the type logic in the conflict check). Let me know if this looks like the right path

[hughsimpson]

Marked as draft for now, shoulda done that earlier, sorry

[hughsimpson]

I've updated the logic around the keys; we should now construct and use a single attribute key with the correct LUB parent type for each specification extension key. Let me know what you guys think.

[hughsimpson]

I could add a parameterised case class here for wrapping the type, maybe? Something like XSpecificationExtension[T]? Kinda easy on the specifics really, just want a way to pass it through.

[kciesielski]

I could add a parameterised case class here for wrapping the type, maybe? Something like XSpecificationExtension[T]? Kinda easy on the specifics really, just want a way to pass it through.

Sounds good to me :)

[hughsimpson]

OK let's try this. Let me know.

[kciesielski]

Nice idea with type aliases. Isn't it enough to have just one level then, without the generic wrapper? AttributeKey[CustomListExtensionOnOperationX] has a different .typeName than AttributeKey[AnotherListExtensionOnOperationX], which is what we were after.

[hughsimpson]

Yeah I prefer it with the single layer too tbh, just thought it was worth trying it out to see how it feels. I'll revert the last pr.

[kciesielski]

LGTM, thanks @hughsimpson!