Flow Url and snapshots issue

I have two flows defined, flowA and flowB. I would typically start these by using the URL's

.../flowA which results in .../flowA?execution=1&snapshot=1
etc.

if I continue with flowA for example to a page midway through the flow so that the snapshots are /flowA?execution=1&snapshot=6 then change the URL to access flow B with the same parameters. /flowB?execution=1&snapshot=6 or any other number within the range of 1 to current active flow snapshot I am actually still within flowA's pages and can carry on executing as if the URL still contained flowA.

Is this what you would expect to be the behaviour?
Could there be a problem with the way that the flow is setup (handlers etc.) ?

Thanks
Greg

I have now created a test flow with a really basic template configuration that I generated from SpringSource Tool Suite. This problem also occurs here. I created flow A with 3 pages two view states and an end state and flow B with two views states and an end state.

i navigated to the second page of flow A and then changed the URL to say flow B and it again carried out flow A using the wrong url.

This test has a very basic configuration and has the same behaviour that I was experiencing before.

Is this likely to be a bug in Spring Webflow?

I appreciate this scenario is very unlikely. Does Spring only use the url for the initial creation of the execution and snapshots and there after just uses the active flow?

The reason I came across this was that I was trying to simulate a SnapshotNotFoundException when switching to a different flow and it carried on in the current active flow.

I haven't looked deeply into this, but my understanding is the name of the flow is usually used for invoking it for the first time. If you're supplying the execution and snapshot IDs, these are used to uniquely identify an execution, which knows everything about where you are in which flow (as well as your entire state), so the flow name you supply doesn't really have anything to add that's important. My guess is that it just gets ignored.

Without knowing what's going on under the hood, I can certainly see why this isn't expected behavior. I DO have to ask, though, what you feel the expected behavior should be. Keep in mind that subflow names are not reflected in the URL as they are executed. Should they be? Or should the URL keep the name of the top-level flow? Maybe it should be based upon the name of the view-state? Or, as you suggest, maybe it should just throw a SnapshotNotFoundException, even though the flow execution ID and snapshot ID uniquely identify the snapshot already.

If I didn't know what was going on internally, I would say your expectation makes sense. However, when you DO know that you've already uniquely identified the snapshot, the proper action to take isn't so clear. I can understand why they're ignoring that, for now.

I mocked two separate flows that were not part of any hierarchy and swapping between them by altering the url and leaving the snapshots I was expecting some form of exception to be thrown such as SnapshotNotFoundException for example.

I can understand the reasoning of the execution already existing and it ignoring the URL however I can imagine this causing problems.

Take for example a user visits your site and bookmarks say the second page of flowA so the ids would be e1 and s1.
They visit again and browse around the site hitting another flow by mistake and therefore decide to use the bookmark. Due to the keys matching and them not by passing the end state of the existing flow they would be directed to the incorrect page.

I appreciate this example is some what far fetched but I can image rare occurrences where this could be a problem.

The configuration where I noticed this issue was quite complex and for that reason I created a new project with basic Spring Webflow and JSP's with the bare minimum webflow configuration without any customised handlers etc. to see if the problem still occurred so it appears that this is the standard webflow behaviour that you describe.

Can you see this as being an issue that would need to be raised as a ticket for someone to look at during a later release?

I agree that it warrents another look and possibly better handling.

On a technical note, SWF doesn't work well with bookmarking, and I suspect any user who tries to bookmark pages in a flow execution might run into unexpected behavior. After the session has been cleaned up, the execution and snapshot IDs are useless, and the flow provided in the URL will start from the beginning. Of course, if their session is still up, but the snapshot cleaned up, then they'll get an exception.