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
Let's suppose one has a common Auth axum extractor which is responsible for authorizing incoming requests, returning 401 responses in case of error. Assuming that, for some reason the OperationOutput needs to be manual (and not generated by the OperationIo macro), one possible implementation would be to:
implOperationInputforAuth{fnoperation_input(ctx:&mutGenContext,operation:&mutOperation){let t = TransformOperation::new(operation);
_ = t.response::<401, http::Error>();}}
Notice that, to reduce boilerplate code and leverage all existing TransformOperation convenience methods (which also provides some error checking under the hood), the implementation wraps the &mut Operation over an TransformOperation.
However, that wouldn't work. When executing the program, the following panic is raised:
already borrowed: BorrowMutError
The errors happens due to the fact that, when aide invokes the operation_input method, it mutably borrows the GEN_CTX thread local, keeping a reference until after such a method finishes. Then, inside operation_input, while the former borrow is still alive, the TransformOperation::response method also tries to borrow it, resulting in a panic.
I don't think if TransformOperation is intended for such manual implementation use cases. However, I really think it should, as it allows for a much nicer and robust interface.
I am opening this issue to try to think about options to solve this issue. See, if operation_input gets a &mut Operation, it would make sense to make one able to create a OperationTransformer over it, right?
A viable option I see is to create a new transformer, OperationTransformerWithCtx, which could be created with both &mut GenContext and &mut Operation. Since it would be more general, to avoid duplication, the current OperationTransformer could be internally reimplemented to use its with ctx counterpart.
WDYT?
The text was updated successfully, but these errors were encountered:
I'm also running into this issue and have not found a workaround. Manually editing the operation does not seem very efficient, so it would be nice if this was supported.
Let's suppose one has a common
Auth
axum extractor which is responsible for authorizing incoming requests, returning 401 responses in case of error. Assuming that, for some reason theOperationOutput
needs to be manual (and not generated by theOperationIo
macro), one possible implementation would be to:Notice that, to reduce boilerplate code and leverage all existing
TransformOperation
convenience methods (which also provides some error checking under the hood), the implementation wraps the&mut Operation
over anTransformOperation
.However, that wouldn't work. When executing the program, the following panic is raised:
The errors happens due to the fact that, when aide invokes the
operation_input
method, it mutably borrows theGEN_CTX
thread local, keeping a reference until after such a method finishes. Then, insideoperation_input
, while the former borrow is still alive, theTransformOperation::response
method also tries to borrow it, resulting in a panic.I don't think if
TransformOperation
is intended for such manual implementation use cases. However, I really think it should, as it allows for a much nicer and robust interface.I am opening this issue to try to think about options to solve this issue. See, if
operation_input
gets a&mut Operation
, it would make sense to make one able to create aOperationTransformer
over it, right?A viable option I see is to create a new transformer,
OperationTransformerWithCtx
, which could be created with both&mut GenContext
and&mut Operation
. Since it would be more general, to avoid duplication, the currentOperationTransformer
could be internally reimplemented to use its with ctx counterpart.WDYT?
The text was updated successfully, but these errors were encountered: