You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: extend resource middlewares to resource templates (#582)
The existing logic for resource middlewares was based heavily off of the
prior art for tool middlewares. Tools, however, don't have the concept
of templates. This change ensures that resource middlewares also get
applied to resource templates.
While they are defined as separate types, both `ResourceHandlerFunc` and
`ResourceTemplateHandlerFunc` have the same function signature, and
therefore satisfy the same underlying type. This seems intentional since
resource templates are only actually executed within the same
`handleReadResource` function, and only when A) no direct resources
match and B) the resource uri matches the template -- executing in the
same function and returning an `mcp.ReadResourceResult` regardless of
direct resource or template.
Since the uri needs to match in order for the template to be executed,
we build the chain of middleware funcs after matching the uri to avoid
wasted cycles. In order to apply the middlewares to the
`ResourceTemplateHandlerFunc`, we explicitly cast to a
`ResourceHandlerFunc`. This is safe, as they point to the same
underlying type. If resource handler funcs ever diverge, this should
also safely surface as a compile time warning, allowing ample time to
address and not have a silent breakage slip through in builds.
Signed-off-by: TJ Hoplock <[email protected]>
0 commit comments