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

Properly handle the route parameter in the orchestrator #881

Open
JRegimbal opened this issue Sep 12, 2024 · 0 comments
Open

Properly handle the route parameter in the orchestrator #881

JRegimbal opened this issue Sep 12, 2024 · 0 comments
Labels
enhancement New feature or request infrastructure

Comments

@JRegimbal
Copy link
Collaborator

New changes to our data model allow for a ca.mcgill.a11y.image.route parameter, which is defined in this comment and allows for clients to select a subset of preprocessors and handlers relevant to a task. This is primarily intended for use with follow-up queries.

For each request, the route parameter must be used if present and assumed to be default if not. Invalid requests will be rejected. For every preprocessor and service, only those with a route label that matches the parameter provided in the request will be run.

E.g., assume the following preprocessors and handlers:

  • PP_A with a label value of "default,followup"
  • PP_B with a label value of "followup"
  • PP_C with no label set.
  • H_A with no label set.
  • H_B with a label value of "default,followup"

If a request is received with no route value or a route of "default", PP_A, PP_C, H_A and H_B would run.
If another request is received with a route value of "followup", then PP_A, PP_B, and H_B would run.

An activity diagram is included below to help clarify the necessary checks, though note that the process of getting a list of preprocessors or handlers and sending information to them has been collapsed into a single loop. This is not how it would run in the orchestrator, and is done here to avoid unnecessary repetition of the checking logic.

An activity diagram illustrating the desired route checking behavior

@JRegimbal JRegimbal added enhancement New feature or request infrastructure labels Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request infrastructure
Projects
None yet
Development

No branches or pull requests

1 participant