spiff-element-units/ARENA_INTEGRATION.md

Spiff Arena Integration

Current State

spiff-element-units v0.1.0 is added to the backend. Currently feature flagged off by default. When on it saves each process instance workflow specs to the cache. When an instance is resumed it can use the cached workflow to run the remaining portions of the process.

Open Questions

1. seeding the cache with all workflow specs
2. updating the cache on save/upload/commit
3. is the current cache key optimal?
   1. needs to be the hash of hashes
4. eventually dropping the cache and merging with current tables
5. the full workflow spec is going to need to be loaded once per atomic unit
   1. if any of the workflow files change, the full workflow spec needs to be cached
   2. once cached, ideally we never need to do it again (until change) to start an instance
6. everything is namespaced by process id, can a call activity use its spec?
   1. how does this work for save/restore?
7. for an atomic unit, what would happen if many instances cloned the same task tree?
8. what happens if a subset of a workflow is used at some stage?
9. what happens if "phantom" process/element ids are in this workflow subset
10. what happens if real process/element ids are in this workflow subset
11. what happens if call activity subspecs are not returned
    1. spiff will throw a key error
    2. can we requery and get the element unit for the call activity spec?
    3. ^ recursively for nested call activities
    4. can this be the same as if the called process was run directly?
12. what happens if anything that applies to call activities is done to subprocesses?
13. do lanes affect the ability to decompose anything?
14. how can a subset of a workflow complete without confusion that the main workflow is complete?
15. can decomposed workflows trip an escalation (or something similar) to signal another trip to the cache?