[Feature Request]: Add option to open execution.

[CarlosJuncher03]

What would you like to happen?

When running production pipelines that run only once, such as database migrations, I frequently use the Open execution option. This feature is especially useful when working with ETL Metadata and sub-pipelines.

However, there is a limitation in scenarios where multiple instances of the same sub-pipeline are opened simultaneously. If one of these executions finishes successfully, I cannot easily access the other instances that are still running to monitor the individual progress of each one.

The suggestion is to create a modal window that allows selecting which execution of the sub-pipeline should be opened, especially when the sub-pipeline receives different parameters in each call.

A possible approach would be to group the parameters received by the execution into a string separated by semicolons (;), displaying this information in the modal to facilitate the identification of each running instance

Issue Priority

Priority: 3

Issue Component

Component: Hop Gui

[hansva]

That's where we point back to the execution information perspective. That option is just to follow the active execution and not to look back at previous ones

[CarlosJuncher03]

I agree with you. Currently, when developing a continuous flow pipeline with transformations like Execute Pipeline or ETL Metadata Injection, the Open Execution feature works well, as long as copies aren't applied to these transformations.

The limitation arises when we create multiple copies of these transformations. For example, in a subpipeline transformation, when creating copies, the flow lines are divided among them. In this scenario, I observe two situations:

First, I can't visualize, during the flow execution, which ongoing execution corresponds to a given parameter received by the pipeline. In larger flows, such as table migrations or extractions, it's common to execute several operations in parallel to save time. Allowing the user to choose which execution to view would be a significant usability gain.

Second, when there are several copies and one of them is finished, accessing Open Execution seems to only direct to the finished execution. It would be useful to also be able to access the other executions that are still in progress.

I don't know if I've explained the idea clearly, but I believe this improvement would make sense. I see this as a significant usability gain, especially in pipelines with a more visual approach, such as migrating data from one database to another.

[CarlosJuncher03]

Open Execution is an excellent feature and represents a significant improvement for monitoring executions.

This activity aims to present a suggestion for usability improvement, based on situations observed in the daily use of the tool. The idea is not to point out a critical flaw, but rather to propose an evolution that can make the experience even clearer, more practical, and more efficient, especially in scenarios with multiple simultaneous executions.

[mattcasters]

The suggestion is to create a modal window that allows selecting which execution of the sub-pipeline should be opened, especially when the sub-pipeline receives different parameters in each call.

This would require the multiple executions to be kept in memory with probably a host of other complications attached to it. It's not that it's a bad idea. The issue is that it's likely not that simple.

[CarlosJuncher03]

I understand, I thought it would be simpler. I believed the information was already stored in memory and that the parameter passed through the pipeline could access that information.