I am noticing behaviour in the Refresh button on the portal where items upsteam of the refresh button are getting affected. This is also occurring with some nodes which have the Re-execution option. The issue is not visible when run on AP, however when run on the Server it appears, which also adds to challenge as the development environment behaviour is not the same as the Server.
In the image below, the ‘Project Basics’ has the refresh/re-execution within it, however the ‘Overall’ values are getting reset each time the refresh/re-execution in ‘Project Basics’ run. Both are subcomponents within another component, which forms the webpage. It seems like ‘Overall’ is clearly upstream of the ‘Project Basics’ component, so this refresh functionality seems strange? If this is per design, what options are there to eliminate this issue WITHOUT creating 2 separate webpages for ‘Overall’ and ‘Project Basics’?
this indeed should not be the case - only strictly everything that is downstream should be re-executed, be it from a Refresh Button or another Widget. I tried to recreate your situation in this workflow, with no luck of getting a re-execution of an upstream node. Did I recreate your situation correctly? Cold you maybe have a look and adapt the workflow so that it recreates the issue?
See the workflow attached (using a re-execution as opposed to a refresh, however the same behaviour is observed with Refresh widget). Insert discount rates and project names in screen 2, then change the utility-state dropdown a few times. The discount rates and name clear after a few runs. Hoping this is just a config issue on my end!
@marvin.kickuth already answered your support request, and I want to let the community know at this place as well: thanks to your example, we were able to identify the issue (internal reference: WEBP-919). It occurs when the re-execution part takes long (>250ms) and this messes up the “frontend”, i.e. the webpage, where it the whole page in the Webbrowser is refreshed. Other workflow branches are not unintentionally executed. But still, this means that any input in unrelated widgets is lost, unfortunately.
So until this is fixed, the gist would be to make the execution of the re-executed part(s) as efficient as possible to stay under 250ms. Even running the workflow on a strong machine helps: I couldn’t reproduce this on a machine using an AMD EPYC 7313P 16-Core-Processor.
I played a little with your workflow and can give a few remarks:
The Inject Variables (Data) node is rarely needed - if you connect the flow variables directly to the component output, they are available at the end of the component
Nodes like CSV Readers potentially take quite some time, as they access the hard drive (which is in general even on a different machine, give you have distributed executors, so network traffic would be involved as well) - if its constantly the same file that is read, you can pull them out of the re-executed branch and/or replace them with a Table Creator, or faster readers like the Table Reader, if suitable.
Off topic, but since I ran into these kind of issues before as well: Date&Time is rather nasty, as it has a lot of edge-cases. If my guess is correct that you want the last day of the tenth month ahead, I’d add 11 Months and subtract 1 day to have leap years, februaries and all these blessings be handled by the nodes
As a workaround for now, and since it looks feasible from your small example, you may avoid re-execution at all by concatenating the drop downs, i.e. have one Utility - State - Zone option (instead of two dropdowns for each Utility - State and Zone) with the options
Not beautiful, but will get you around the issue for now. The Cross Joiner could help creating the options and you might want to switch to the Autocomplete Text Widget in case the options become overwhelmingly many.
