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

ISW - Wizard Step: Start Input Step #20567

Open
grotlue opened this issue Sep 26, 2024 · 6 comments
Open

ISW - Wizard Step: Start Input Step #20567

grotlue opened this issue Sep 26, 2024 · 6 comments

Comments

@grotlue
Copy link
Contributor

grotlue commented Sep 26, 2024

  • When switching to this step, the input and everything else configured in the previous steps will be excuted
  • It shows a list of all the steps that have been completed
  • It shows errors and error messages of failed steps
  • Next Step: ISW - Wizard Step: Input Diagnostics #20683

4748b276-c649-488f-b8df-87271083e97b#media-blob-url=true id=b9b9b4a3-697e-49b0-890f-2ee61c9e5677 contextId=10149 collection=

@tellistone
Copy link

Maybe we present the text as showing what will be done (eg. Input "my Big Input" will be started!) rather than what is already done

We discussed performing the actions sequentially, and showing user error of which step fails in event of fail

we discussed rolling anything we created here back, in the event of a fail

@tellistone
Copy link

if the input no longer exists or is not in setup mode when you press OK, handle that exception

@grotlue grotlue removed the backend label Nov 6, 2024
@tellistone tellistone changed the title Wizard Step: Completion Step Wizard Step: Start Input Step Nov 6, 2024
@grotlue grotlue added the backend label Nov 8, 2024
@tellistone tellistone changed the title Wizard Step: Start Input Step ISW - Wizard Step: Start Input Step Nov 14, 2024
@grotlue
Copy link
Contributor Author

grotlue commented Nov 14, 2024

Steps that are executed

Always

Illuminate

  • Not in scope for this cycle, but with adding the Illuminate flow, we will have more steps here (will be added in a seperate issue)

Routing

Option 1 - Use default stream

  • No extra routing necessary

Option 2 - Use existing stream

Option 3 - New Stream

@patrickmann
Copy link
Contributor

Regarding the APIs for routing: For options 1 and 2, I suggest we introduce a new API put /system/pipelines/pipeline. Same as put /system/pipelines/pipeline/{id}, but BE will add the rule to default pipeline (and create one, if it doesn't yet exist). Since the payload source field includes the pipeline name, we need to use the same in FE and BE.

Alternatively, the new endpoint could just take an input ID as the parameter. BE would then create the rule and add it to a default pipeline. This would reduce coupling between FE and BE.

Re option 1: What default stream is this referring to? According to #20568, user either selects an existing stream or creates a new one.

@grotlue
Copy link
Contributor Author

grotlue commented Nov 18, 2024

Re option 1: What default stream is this referring to? According to #20568, user either selects an existing stream or creates a new one.

Default is: All messages (Default Stream)

Both API options sound fine for me. Both would need the pipeline name (nullable -> which means default) and the input id passed, right?

@grotlue
Copy link
Contributor Author

grotlue commented Nov 19, 2024

Discussion outcome 19.11.2024

  • For messages to work with Illuminate, we need them to be in the Default Stream first. That's one of the reasons why we prefer pipeline rules over stream rules.
  • We need an immutable pipeline for wizard-related routing (e.g. "built-in" or "system" pipeline)
    • we always add rule to stage 0
    • in this case immutable means:
      • not deletable
      • can't be renamed
      • connections can't be changed
      • rules can be deleted, added, edited
    • Alternative approach: pipeline is deletable, but will be recreated immediately
      • That would lead to users potentially messing up routing that was created by a wizard (we can live with that though)
      • less effort as it won't need UI adjustments
      • we decided to go for this option even though the pipeline won't be immutable in this case

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

No branches or pull requests

3 participants