Skip to content
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

Middleware specificity stalemate resolution - Middleware deferring #2690

Open
Permik opened this issue Oct 6, 2024 · 0 comments
Open

Middleware specificity stalemate resolution - Middleware deferring #2690

Permik opened this issue Oct 6, 2024 · 0 comments

Comments

@Permik
Copy link

Permik commented Oct 6, 2024

Hi!

I'm unfortunately running into a problem where I have multiple plugins/handlers (in said plugin) running with equal specificity and one of the handlers needs data from another of the handlers.

Because this essentially results in a stalemate/undefined execution order when running handlers/middleware with equal specificity I'd propose an API to defer the call of the middleware/handler.
Essentially the api should look something like this:

(
        req: Request,
        ctx: FreshContext<AuthPluginState>,
      ) => {
        if(ctx.state.i_need_this_data == undefined) return await ctx.defer();
}

This'll essentially just add the handler again to the end of the current specificity callstack so It'll be called again when the other handlers have ran and hopefully the data has been set to the state.

Does this seem impossible, or is there some better way of achieving this behavior?
(Like a promise that I await in the state object? If yes, could this be documented? :D)

meta: I'm not open to smashing all of the handler logic together into a single function as they are encapsulated well and each handler runs with "the least privilege possible" and every handler is really clear what is it's responsibility.

EDIT: Seems I just need to rework the code to scope itself better. The original way I did the things I needed was less verbose, but the reworked code will just instantiate more preconfigured generated functions from the plugin config and pass them forward.

I'll try to document the refactoring at some point, that someone that hits this issue will have some guidance how to go forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant