ADF Task Flow Binding - Refresh ifNeeded being invoked even WITHOUT any Parameter change

Question

Using JDeveloper 11.1.1.6.0
Issue: Task Flow Binding property "refresh = ifNeeded" seems to be triggered even without the mutation of the input parameter.
As per definition, "ifNeeded: refresh the ADF Region if the value of a task flow binding parameter changes." (Reference: 17.5 Refreshing an ADF Region)
Now for the setup which reproduces the issue.
I'll focus at the fragment bounded task flow level and will skip the jspx side.
taskflow: main-flow.xml
contains a single fragment mainFgmt.jsff
has a managed bean defined SampleBean.java as pageFlow scope.
taskflow: sub-flow.xml
contains a single fragment subFgmt.jsff
has an inputParameter SampleBean.java (because it is an input parameter, by default it will be at pageFlow scope)
!important - has a nested taskflow (task flow call as defined in the component pallete) called inner-flow (see below)
the nested taskflow is the default activity
the nested taskflow has an outcome pointing to subFgmt where outcome = "return"
taskflow: inner-flow.xml
contains a single fragment called stop.jsff
has a return activity without outcome = "return"
stop.jsff has a navigation pointing to the outcome.
Finally mainFgmt.jsff has a task flow binding (pageDef)
with id = "sub-flow.xml"
refresh = "ifNeeded"
parameter SampleBean being submitted as sub-flow's input parameter. (id=sampleBean, value=#{pageFlowScope.mainSampleBean})
Assume that code compiles.
In this scenario where the only tricky condition is the inner nesting (defined by !important), when the inner nesting decides to invoke its outcome to visit sub-flow's fragment, mainFgmt is restarting its taskflow which makes sub-flow start over again.
Another way of saying it is, if sub-flow starts a nested activity and that nested activity exits out to utilize sub-flow's view. The high level definition which is mainFgmt's refresh ifNeeded is restarting sub-flow.
In the above example if you notice, the bean (SampleBean) is not really being utilized except that it is completing the purpose of refresh=ifNeeded. This scenario is only to simplify the setup - in practical use this bean will be mutated to be utilized as a refresh mechanism.
Now interestingly, if I change the pattern a bit then the issue will not happen:
Don't use the nested taskflow (inner-flow) as the default activity, let a fragment of sub-flow hold the initial view.
Navigate to the nested flow.
Exit nested flow.
Everything works.
Now in this scenario, it seems like the sub-flow needs to have a view established first for it to be properly be used.
So my questions are as follows:
Can I consider the behavior of the refresh=ifNeeded as a bug in this usecase?
Would it be better to utilize a different way of refreshing (maybe combination of refresh condition) to get around the issue?
Is the use of the task flow as defined logical or does it cross any boundary or best practice that might be causing this behavior?

Answer 1

Hi,
actually you lost me in your description due to complexity. I lived under assumption that sub-flow already is a region on a view in main flow, but then you sad that
"!important - has a nested taskflow (task flow call as defined in the component pallete) called inner-flow (see below)"
which then confused me as to I have no idea if inner flow now is the second level nesting or first level nesting (should be second level nesting). If sub-flow is a region then having "has an inputParameter SampleBean.java (because it is an input parameter, by default it will be at pageFlow scope)"  is an unnecessary broad scope because the region wont live longer than view scope.
Anyway, it seems that a region refresh is triggered by the lifecycle involved, which can be by design or a bug. I suggest you file a Service Request with support and provide a test case as purely from the description, its hard to parse and understand what is going on.
Frank