Response disappear #2

[Alex Shubert]

Hi everyone. 

Let's assume that I have 3 messages in a queue:

```

1. REPROCESS

2. REPROCESS

3. INIT

```

The order is somewhat important as this is how responses are read from SQS in reader's loop. 

INIT message makes reader to call `engine.run('flow-name', INIT)`. `REPROCESS` singles to perform some repeating activity. The problem is, that in audit I can see that WorkFlow performs `INIT`, one `REPROCESS` and waits in infinite wait. Second `REPROCESS` event is disappeared. Every activity takes 3 seconds at most, so it shouldn't be autoclaving as it's performed every 1 hour, right? I use `getAndRemoveResponse` to read the responses, not `getAndRemoveResponses`. Code in Workflow.java seems to handle things correctly... There is nothing in `cop_response` table. 

What could be wrong?

P.S.: SQS doesn't guarantee FIFO and I don't think that is good idea to mark incoming messages to restore order.

[Michael Austermann]

Hi Alex,

just to make sure that I got it:

INIT events are creating a new workflow instance.

REPROCESS events are "responses" and are given to the engine using engine.notify using "REPROCESS" as correleationId.

The REPROCESS events are processed before the INIT, right?

Have you tried "getAndRemoveResponses"?

Does it return one or two responses?

There is one thing you should keep in mind:

When a workflow instance is resumed after a wait call, all corresponding responses for this workflow instance in the database are read.

Each of these responses that you do NOT retrieve using getAndRemoveResponse or getAndRemoveResponses are discarded when calling the next "Workflow.wait..".

Or is it the other way round? INIT first and REPROCESS, REPROCESS next?

/Michael

---

Von: "Alex Shubert" <alex.s...@gmail.com>
An: "COPPER Engine" <copper...@googlegroups.com>
Gesendet: Dienstag, 25. Oktober 2016 14:13:31
Betreff: [COPPER Users] Response disappear #2

--
You received this message because you are subscribed to the Google Groups "COPPER Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to copper-engin...@googlegroups.com.
To post to this group, send email to copper...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/copper-engine/162db9ed-d12f-49b1-8f1c-b97faf641bc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Shubert]

Thank you for response and sorry for not being clear enough. 

This is how it works now. 

```

def handleSQSMessage(correlationId: String, event: MyEvent) = {

  event match {
  case SignupEvents.SIGNUP ⇒
    engine.run("SomeFlow", correlationId)
  case evt ⇒

    engine.notify(new Response(correlationId, evt, null))

  }

}

```

Messages are coming from SQS and most of the time in LIFO manner instead of FIFO. For example, user could enter survey (INIT) (this should start workflow) and give some answers (REPROCESS, REPROCESS). correlationID is build as userId salted some specific data. 

SQS tends to return them in inverted order, i.e. (REPROCESS, REPROCESS, INIT). 

Each of these responses that you do NOT retrieve using getAndRemoveResponse or getAndRemoveResponses are discarded when calling the next  

Oh. This is the answer I believe. Can't find it in sources but this perfectly explains anything.

Thank you!