-
Notifications
You must be signed in to change notification settings - Fork 5
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
Operation dispatcher FSM #77
Conversation
d1d196b
to
a66a992
Compare
ca3cdff
to
876b38f
Compare
ed8eec1
to
6c9343d
Compare
90d45ee
to
b513b69
Compare
88c2caf
to
2b288a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some notes, but I think this is good starting point... Let's iterate!
{ | ||
#[allow(non_upper_case_globals)] | ||
static instance: ::protobuf::rt::LazyV2<GrpcMessage> = ::protobuf::rt::LazyV2::INIT; | ||
instance.get(|| GrpcMessage::RateLimit(RateLimitRequest::new())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The requirement for this confuses me... couldn't this "just" be a factory function and be passed around as a fn pointer instead? Not a big deal tho
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one was to please the compiler, got the implementation from the message lib xD
self.operations.borrow().first().unwrap().get_result() | ||
} | ||
|
||
pub fn next(&self) -> Option<Operation> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this signature will need to be somewhat rethought... Probably something along the lines of a
.start()
that starts a "sequence",initial
state (that would only be started inon_request_headers
phase).next(...)
with some params (gRPC response'stoken_id
&response_size
?) to go from one operation to the next (that would only ever be progressed inon_grpc_response
phase,Pause
with the request)()
i.e. "void"/unit, i.e. nothing left to do, representing theterminated
state (transitioned to in theon_grpc_response
phase, possibly leaving more work for some other phase to handle,Continue
with the request)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, after discussing about how would it be consumed on_grpc_response
and the requirements to digest the actual response needing the response_size
makes sense. Will shoot a following PR addressing this. Thanks!
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
* Could get confusing with proxy_wasm `Actions` * Also with plugin configuration `Action` Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
* GrpcMessage type created Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
Signed-off-by: dd di cesare <[email protected]>
* Easier to test, mocking fn * Assigned fn on creation, default hostcall and mock on tests Signed-off-by: dd di cesare <[email protected]>
* Bonus: Addressed review regarding testing and Fn types Signed-off-by: dd di cesare <[email protected]>
de5060e
to
c221036
Compare
I want to understand and follow. Shouldn't the distpatcher be called on the |
@eguzki you're correct, it should be call on |
ok, let's go then. Forget about the clippy thing for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's iterate! 🔨
Part of the work needed for #58
This PR introduces the OperationDispatcher FSM, that it's responsible of not only keeping track of the current state of the operations, but also triggering the actual actions defined by configuration.
It also includes a refactor that was needed in order to wire the Filter, Services, ServiceHandlers and Operations together.
The implementation:
OperationDispatcher
:next
function in charge of triggering the currentOperation
procedurenext
fn will return the currentOperation
when called.Operation
:State
,Result
andExtension
State
(Pending
->Waiting
->Done
)hostcalls
fnsRegarding the refactoring of the other pieces:
GrpcMessage
was created, implementing the traitMessage
in order to abstract its logicGrpcService
now keeps aRc
ofExtension
GrpcServiceHandler.send
method takes as argsget_map_values_bytes
andgrpc_call
following DI pattern in order to unit test the operations.Actions
have been added.Notes
Rules
from thePluginConfiguration
follows still the old state, duplicatingDataType
that resides within theActions
service
module