Private message fails with "No match for zerohash"

[awrichar]

Saw this issue repeatedly in a demo application when sending a private message to self. The interesting log is this one:

[2023-12-11T16:35:34.344Z]  WARN No match for zerohash on context: group=5a70dc579baeb52a50fc69594e8a404b726269ccfeac6ec40f232d9c728a421e topic=a133547a-d104-46f8-aed2-7911a48d7ae6 context=b5537c66e694ae1fd792b08c40ef75ed8c2faf3e9e562ff3ec16f6de54ad14a7 pin=80ad901239cc9f914907639fe4e0b19b341a3c03a1da12292f540f8f5fb2859a dbtx=otysQbSl ns=org1-ff->mynet pid=1 role=aggregator

Some details on the failed message:

• Message: e284e1c6-073f-404c-bfb5-2e362efd3590
• Batch: 5941e40a-564b-46c1-8e34-e8b5e206f6ae
• TX: 28fa55dc-4e18-4762-8f05-e0caaa38b1e2
• Pin: 19

Full logs: ff.txt

[peterbroadhurst]

Initial finding:

In this case, the pin being passed into the attemptContextInit is the nonce: 1 pin, not the nonce: 0 pin.

So I need to track back into what might cause attemptContextInit() to be driven twice in this scenario.

[peterbroadhurst]

In the message I can see it's for nonce=1:

    "pins": [
        "80ad901239cc9f914907639fe4e0b19b341a3c03a1da12292f540f8f5fb2859a:0000000000000001"
    ],

[peterbroadhurst]

There is an earlier message with nonce:0 so I need to track back to that:

[2023-12-11T16:35:30.292Z] DEBUG Assigned pin 'b36848dff6febe7596d8daab9fb220f80165355d2311b2ad485f9e7f7a10e5cb:0000000000000000' to message 5398c6ad-9274-4061-bc35-9b83d0631e2e for topic 'a133547a-d104-46f8-aed2-7911a48d7ae6' d=pinned_private dbtx=wyQUq4Yj ns=org1-ff->mynet p=did:firefly:org/org1|5a70dc579baeb52a50fc69594e8a404b726269cc... pid=1 role=batchmgr
[2023-12-11T16:35:31.289Z] DEBUG Assigned pin '80ad901239cc9f914907639fe4e0b19b341a3c03a1da12292f540f8f5fb2859a:0000000000000001' to message e284e1c6-073f-404c-bfb5-2e362efd3590 for topic 'a133547a-d104-46f8-aed2-7911a48d7ae6' d=pinned_private dbtx=flwqCjXU ns=org1-ff->mynet p=did:firefly:org/org1|5a70dc579baeb52a50fc69594e8a404b726269cc... pid=1 role=batchmgr

[peterbroadhurst]

Ok - the problem here is that we are using different signing addresses for the two messages.

The second overtakes the first on-chain - because they are on different signing addresses.

So the nonce:1 message arrives before the nonce:0 message on-chain.

[2023-12-11T16:35:30.363Z] DEBUG Dispatched batch a15eca05-f80c-4cee-be1b-98d303e3ed30 d=pinned_private ns=org1-ff->mynet p=did:firefly:org/org1|5a70dc579baeb52a50fc69594e8a404b726269cc... pid=1 role=batchmgr

[2023-12-11T16:35:31.347Z] DEBUG Dispatched batch 5941e40a-564b-46c1-8e34-e8b5e206f6ae d=pinned_private ns=org1-ff->mynet p=did:firefly:org/org1|5a70dc579baeb52a50fc69594e8a404b726269cc... pid=1 role=batchmgr

[2023-12-11T16:35:34.320Z]  INFO <- BatchPinComplete batch=5941e40a-564b-46c1-8e34-e8b5e206f6ae txn=000000001640/000000/000000 signingIdentity=0x603791eda57ef488e3b73ee666863e58b3f3f27a dbtx=uloAaZBZ ns=org1-ff->mynet pid=1 role=event-manager

[2023-12-11T16:35:34.321Z]  INFO <- BatchPinComplete batch=a15eca05-f80c-4cee-be1b-98d303e3ed30 txn=000000001640/000001/000001 signingIdentity=0x94df48bdd3d5cc4861b32142d1f23b5bf4e9c6ab dbtx=uloAaZBZ ns=org1-ff->mynet pid=1 role=event-manager

[peterbroadhurst]

Need to consider what the right answer is to this (code, architectural assurances, programming requirements, or otherwise), given the laws of physics of the blockchain when ordering, and the requirements around ordering.