-
Notifications
You must be signed in to change notification settings - Fork 58
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
[FEATURE] Replace TransportActions class functionality in SDKActionModule #467
Comments
@saratvemulapalli assigning this to you as you did #164, are continuing to iterate on dynamic actions, and may have better ideas than I did above for implementation. Feel free to reassign back to me if you prefer a direction and don't have time to do it -- just let me know which way to go. |
@dbwiddis Trying to catchup from PR: #466 Looks like we do have
|
The same way they already were (or weren't, due to bug #484) with your previous Background: You previously had a In #434 I added the default List<ActionHandler<? extends ActionRequest, ? extends ActionResponse>> getActions() {
return Collections.emptyList();
} We could not have an extension (e.g., - default Map<String, Class<? extends TransportAction<? extends ActionRequest, ? extends ActionResponse>>> getActions() {
+ default Map<String, Class<? extends TransportAction<? extends ActionRequest, ? extends ActionResponse>>> getActionsMap() { Now enter #466, the intent was to keep the same action injection that existed in the OpenSearch side, so I copied over the appropriate parts of the public Map<String, ActionHandler<?, ?>> getActions() {
return actions;
} This map has a 1-to-1 correspondence with your map (previous - this.transportActions = new TransportActions(extension.getActionsMap());
+ Map<String, Class<? extends TransportAction<? extends ActionRequest, ? extends ActionResponse>>> transportActionsMap = new HashMap<>();
+ sdkActionModule.getActions()
+ .entrySet()
+ .stream()
+ .forEach(h -> { transportActionsMap.put(h.getKey(), h.getValue().getTransportAction()); });
+ this.transportActions = new TransportActions(transportActionsMap); So this preserves exactly the same registration method you were already using, but since you never tried to register an extension action class, you didn't encounter the bug in #484. A class that exists only on the SDK side cannot be instantiated on the OpenSearch side. So whatever registration we currently have/had is broken. But I know you're also working with Proxy Actions and there is some sort of registration envisioned there.
This is no different conceptually with how we're handling Rest Handlers. We have a local registry of just the Extension's rest handlers, and we register them on OpenSearch's RestController with a single "forwarding" action. OpenSearch doesn't have a copy of the class, it just knows "this REST call goes to that extension". Same thing will be true with actions, we just need that unique (writeable) key registered and OpenSearch needs to know which extension owns that action. |
Completed in #524 |
Is your feature request related to a problem?
The
TransportActions
class contains an internal map that must be provided at instantiation. This map contains the same information inSDKActionModule.getActions()
in a different format and is only relevant for anActionExtension
.This requires unnecessary conditionals outside the class.
What solution would you like?
sendRegisterTransportActionsRequest
method to theSDKActionModule
getActions()
method ofSDKActionModule
to retrieve the necessary map4. Change the handler for actions sent from OpenSearch to use theThis handler doesn't exist. Opened [FEATURE] [DISCUSS] Implement Proxy Actions #525SDKActionModule
getActions()
map (or use the injectedtransportAction(instance)
lookup, or other approach)What alternatives have you considered?
Creating the map outside the class, conditionally populating it, and then initializing it, which was done in #466
Adding a getter for the map to
TransportActions
so it can be initialized once externally (but this seems silly).Do you have any additional context?
Consider whether we need this separate map signature and whether the values from
SDKActionModule.getActions()
are sufficient to serve the intended purpose.The text was updated successfully, but these errors were encountered: