-
|
I've read the current design of an interceptor here and I also played for quite a bit with source code. It looks like currently it's possible to:
It's however not possible to return result directly WITHOUT further evaluation. I don't know Erlang good, so maybe I overlook some trick. I tried code like this, but it fails. intercept(#'queue.declare'{queue = Queue, passive = Passive} = Method, Content, _VHost) ->
case [Queue, Passive] of
[<<"magic">>, true] ->
MagicNumber = 42,
#'queue.declare_ok'{queue = Queue, message_count = MagicNumber, consumer_count = MagicNumber};
_ ->
{Method, Content}
end;Is there any trick for that or is that just a missing feature? Thank you for any help you can provide 🙏 |
Beta Was this translation helpful? Give feedback.
Answered by
SimonUnge
Mar 26, 2024
Replies: 2 comments 9 replies
-
|
Your code looks correct. What is the specific failure you're seeing? If it's a large stacktrace, save it to a file and ATTACH it to your response. Even better, provide a git repository I can clone, with instructions to build and run, to see the same error as you. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Sorry, did not mean to generate more work to you. It's just when I look at the code, it looks like we pass result to further method, so my question was whether this feature is supported at all. See here - we pass result of interceptor to the Here is the log. Interceptor in question is I don't have a public repo, unfortunately. As I am doing that as a part of private source code 😢 Very long log |
Beta Was this translation helpful? Give feedback.
-
|
Your return value is wrong in the first case. You need to return |
Beta Was this translation helpful? Give feedback.
8 replies
-
|
@SimonUnge Yes, you are completely right in your analysis.I want to return result without server actually doing anything. In my interceptor I have very specific logic and I am calculating result myself without falling back to any of the server methods. So I cannot express that in a form of Could you please confirm that it's impossible to do that with the current design? Design talks
That's true. To support "server to client" you will have to change the design of an interceptor to be like a decorator. But I don't need that functionality in my example. Currently you actually can respond back to client right from the interceptor - in case you return an error. But there is no way to signal back if you want to return a successful result. To me that's an inconvenient limitation and a gap in the functionality. Most of the interceptors I met in other products allow you to respond without falling back to the original method. I don't see any possible design reason why you would add such a limitation on purpose. Do you think that something that could be added to the product? |
Beta Was this translation helpful? Give feedback.
-
|
Well, the design is that it intercept the traffic from the client, modifies it - or throws an error - and then passes it along to the server. So it can only create payload the server can handle, in a context the server understands. Is there a way to intercept, do something, and then return to something to the client without passing it to the server? You are of course welcome to suggest new features - and perhaps even implement them. @ansd has deeper knowledge than I do so perhaps he can add his point of view. |
Beta Was this translation helpful? Give feedback.
-
|
I agree with what @SimonUnge wrote. What's the use case of MagicNumber = 42,
#'queue.declare_ok'{queue = Queue, message_count = MagicNumber, consumer_count = MagicNumber};? Why do you want to return queue declaration success with some fake |
Beta Was this translation helpful? Give feedback.
-
|
@ansd Obviously the sample should be perceived as a simplified example to reason about the problem I have and to not be distracted by the logic itself 😉 I do understand that currently it is designed to pass-through patching arguments or failing prematurely. I just think that for interceptor it should be possible to also compute and respond with non-error result without passing through. The use case could be that interceptor could implement the logic inside by calling other internal API. Having a constraint to only pass-through for successful result adds lots of limitations on what could be implemented in an interceptor. |
Beta Was this translation helpful? Give feedback.
-
|
@zvirja and what's why we are asking for more details as to what you are trying to do. Interceptor plugins are a rare thing to see, in part because they are risky and a bug in an interceptor can be catastrophic for the availability of a node that uses it. |
Beta Was this translation helpful? Give feedback.
Answer selected by
lukebakken
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Your return value is wrong in the first case. You need to return
{Method, Content}. You only return Method.