americanexpress/unify-flowret

When resuming a case, the internal method call to writeProcessInfo fails

Closed this issue · 1 comments

I have created a DAO for storing audit and process documents into the database, using the key argument (to the read and write methods) as the primary key of a DB table.
However, when resuming a case, flowret makes an internal method call to ExecThreadTask.writeProcessInfo which fails as it tries to insert the processInfo again, due to duplicate/already existing key for the processinfo log.
Aren't keys supposed to be unique? Or should the write() method implementation in the DAO be made idempotent for a given key (for example using an UPSERT in postgres)? (Since, there is no explanation given in the documentation on what/how the keys should be stored, I had assumed it was a good thing to store it as a primary key. But, then idempotency will have to be implemented to solve this issue. What's the take on this? Is this how it was supposed to be designed?

Hi - there is a sample implementation of DAO using file system in the test cases. Think of the key as identifying a unique record in the database. If Flowret calls the dao again for the same key, then it wants to overwrite the contents. Similar to first inserting a record and then updating it. So yes it is like an upsert - though i would not call it to be strictly idempotent. Yes - it has been designed like this. As regards documentation, the description of particular behaviour may be missed out (which I will update sometime in the future) but I think it is clear from the test DAO implementation.