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

Process Instance Migration: Backend and Frontend Changes to execute a process migration #1671

Closed
Tracked by #1640
danfunk opened this issue Jun 4, 2024 · 29 comments
Closed
Tracked by #1640
Assignees

Comments

@danfunk
Copy link
Contributor

danfunk commented Jun 4, 2024

Placeholder for future sprint - estimation to be determined, I just put a number in here to help guide expectations. Add some tools to the UI and back-end that will allow you to migrate a process instance to an updated model. Will need to check if the migration is possible, which will require that the process instance is in a state where the changes are "up stream" or not reached yet.

@danfunk danfunk converted this from a draft issue Jun 4, 2024
@danfunk danfunk added this to the Process Instance Migrations milestone Jun 4, 2024
@calexh-sar calexh-sar changed the title Backend and Frontend Changes to execute a process migration Process Instance Migration: Backend and Frontend Changes to execute a process migration Jun 12, 2024
@calexh-sar calexh-sar moved this from New Issue to Backlog in SpiffWorkflow Jun 12, 2024
This was referenced Jul 8, 2024
@jasquat jasquat moved this from Backlog to Ready for QA in SpiffWorkflow Jul 11, 2024
@jasquat
Copy link
Contributor

jasquat commented Jul 11, 2024

This has been deployed to qa5 for testing.

@madhurrya
Copy link
Contributor

So if there are 100 instances of a model and if they want to update that model and migrate all the instances, they will have to manually suspend and migrate them one by one for all the 100. Is that how they want to do it?

@madhurrya
Copy link
Contributor

madhurrya commented Jul 12, 2024

Noticed these during my testing today.
#1907 - Closed
#1908 - Closed
#1909 - Fixed
#1910 - Closed

@madhurrya
Copy link
Contributor

@burnettk @jasquat When a message related task/event is active, if we change the Message of that and migrate, there'll be 2 messages for that. The one already created with the old message and the one that got created after the message update.
Is that something we need to worry about?

For example
https://timetracking.spiffworkflow.org/i/6258

Image

@jasquat
Copy link
Contributor

jasquat commented Jul 12, 2024

That doesn't seem ideal but also doesn't seem wrong. Maybe the correct solution is to allow users to manually disable message instances and they will need to be careful about migrating such things.

@madhurrya
Copy link
Contributor

So if there are 100 instances of a model and if they want to update that model and migrate all the instances, they will have to manually suspend and migrate them one by one for all the 100. Is that how they want to do it?

@burnettk any thoughts on this?

@madhurrya
Copy link
Contributor

If we add/remove a Signal boundary event to the current active task, it won't allow us to migrate that instance. Is that some thing we need to worry about?

Image

Image

@madhurrya
Copy link
Contributor

Tested migration at unit test level for these. Please let me know if I have missed anything.

Manual Task
User Task
Service Task
Script Task
Business Rule Task
Send Task
Receive Task
Exclusive Gateway
Parallel Gateway
Inclusive Gateway

Call Activity
Sub process Collapsed
Sub process Expanded

Timers

Data input/output
Data object

Guest user task

Multi Instance (Loop cardinality, Input collection)
Loop

Escalation End Event
Escalation Intermidate Throw Event
Escalation Boundary Event
Escalation Boundary Event (non-interrupting)
Error End Event
Error Boundary Event
Message End Event
Message Intermediate Catch Event
Message Intermediate Throw Event
Message Boundary Event
Conditional Boundary Event
Signal Boundary Event
Timer Intermediate Catch Event
Timer Boundary Event

Lanes

@madhurrya
Copy link
Contributor

madhurrya commented Jul 15, 2024

Issues found today

#1919 - RFQA - Fixed
#1920 - RFQA - Fixed
#1922 - deferring

@madhurrya
Copy link
Contributor

@burnettk @jasquat is there anything to test in data stores related to migration?

@madhurrya
Copy link
Contributor

@burnettk @jasquat when we go to the migration page, it might be better to update the bread crumb to show that you are in the migration page.

Image

@madhurrya
Copy link
Contributor

madhurrya commented Jul 16, 2024

Issues found today
#1928 - Fixed

This might be related to the migration updates, but not sure. It could be due to some other recent code change as well.
#1927 - Fixed

@burnettk
Copy link
Contributor

added "Migrate" to the breadcrumb. that isn't deployed anywhere yet.

regarding having to suspend and migrate 100 process instances individually, yes, that is understand and this is definitely an area to consider as a future enhancement. we tried to build the simplest thing that could possibly work, but definitely had this potential future use case in mind.

@madhurrya
Copy link
Contributor

If we add/remove a Signal boundary event to the current active task, it won't allow us to migrate that instance. Is that some thing we need to worry about?

Image

Image

@burnettk I guess we are going to leave this as it is now?

@madhurrya
Copy link
Contributor

@burnettk @jasquat when a user loops back to a task, it doesn't allow me to change it and migrate it, I think because it was already completed once in the previous iteration. I assume that's how it is expected to work.
image

@madhurrya
Copy link
Contributor

madhurrya commented Jul 18, 2024

Noticed this issue today
#1945 - Fixed

@burnettk
Copy link
Contributor

re: "If we add/remove a Signal boundary event to the current active task, it won't allow us to migrate that instance. Is that some thing we need to worry about?"

that is expected behavior, yes.

"when a user loops back to a task, it doesn't allow me to change it and migrate it, I think because it was already completed once in the previous iteration. I assume that's how it is expected to work."

yes, that is expected.

cc @essweine just in case i am telling lies.

@essweine
Copy link
Collaborator

Yes, both are expected.

@madhurrya
Copy link
Contributor

madhurrya commented Jul 22, 2024

Noticed this issue today
#1961 - Fixed

Please check this one also.
#1962 - Closed

@madhurrya
Copy link
Contributor

@burnettk While a Guest task is active, if we remove the Guest Option from that task and migrated it, still it seems to be assigned to the Guest. Is it the expected behaviour?

@madhurrya
Copy link
Contributor

@burnettk @jasquat It'll be really nice when we show this 'not migratable' message, if we can show which task update(s) is/are preventing the migration, as it becomes confusing sometimes why we can't migrate it. But not sure whether it's going to be practical if there are lot of changes in a model.

Image

@madhurrya
Copy link
Contributor

Adding a note for later reference (as these are mentioned in different places)
In these scenarios we can't update and migrate an instance when that task is active.

  1. Call activity (can't change properties of the call activity itself, but we can update the tasks inside it)
  2. Sub process (can't change properties of the sub process itself, but we can update the tasks inside it)
  3. Multi Instance tasks
  4. Loop tasks
  5. Signal boundary event - add/remove signals
  6. When we loop back through a process which has already completed once

@jasquat
Copy link
Contributor

jasquat commented Jul 22, 2024

@madhurrya the guest task assignment seems like an issue and is an oversight. We do not recreate the HumanTask during migrations but we may need to either recreate or update more properties like assignment.

As far as the not migratable message goes, we are limited in what we information we have that will make sense to the user. We may be able to pull a little more info out of the diffs from spiff but uncertain it will make sense. Right now it hasn't been a requirement but it would be a nice to have.

@madhurrya
Copy link
Contributor

@burnettk @jasquat After an instance is completed we don't have a way to see the migration history of that. Do you think users will need this?

@madhurrya
Copy link
Contributor

madhurrya commented Jul 23, 2024

Please check this issue
#1973 - will not fix it

and this one too
#1974 - not fixed yet

@madhurrya
Copy link
Contributor

@burnettk @jasquat noticed that in Samples site today some times it takes time to load the migration history table. Did anything change there which will take longer or is it just server performance?

Image

@burnettk
Copy link
Contributor

nah, i don't think anything changed in this regard recently. i'm inclined to ignore migration-related performance issues unless it's very annoying. if it works, i'm happy.

@madhurrya
Copy link
Contributor

@burnettk @jasquat @calexh-sar I think I have completed the migration testing.

It might be good to document (and inform the client) about these scenarios.
#1671 (comment)

and about these known issues
#1922
#1973
(#1974 - this one is just an edge case I think, not that important)

@madhurrya madhurrya moved this from Ready for QA to Ready for Release in SpiffWorkflow Jul 24, 2024
@burnettk
Copy link
Contributor

Incorporated these issues into the documentation as known issues and caveats, thank you.

@github-project-automation github-project-automation bot moved this from Ready for Release to Resolved in SpiffWorkflow Aug 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Resolved
Development

No branches or pull requests

5 participants