hyperledger / firefly

Hyperledger FireFly is the first open source Supernode: a complete stack for enterprises to build and scale secure Web3 applications. The FireFly API for digital assets, data flows, and blockchain transactions makes it radically faster to build production-ready apps on popular chains and protocols.
https://hyperledger.github.io/firefly
Apache License 2.0
508 stars 209 forks source link

Protocol ID behaviour inconsistent with docs #1455

Closed hosie closed 3 months ago

hosie commented 10 months ago

docs say

000003 - this is the event (/log) index within that transaction

However, what I observe is that the value in this segment increases across transactions and only resets to 0 on a new block. So itsems to be the event /log index within a block.

e.g. when I have 1 event per transaction, 2nd segment and 3rd segment are always equal.

"000000112840/000006/000006"
"000000112840/000005/000005"
"000000112840/000004/000004"
"000000112840/000003/000003"
"000000112840/000002/000002"
"000000112840/000001/000001"
"000000112840/000000/000000"

If I have 2 events per transaction, then I see segment 3 increase sequentially on every event and segment 2 increases by one on every other event

"000000147029/000004/000009"
"000000147029/000004/000008"
"000000147029/000003/000007"
"000000147029/000003/000006"
"000000147029/000002/000005"
"000000147029/000002/000004"
"000000147029/000001/000003"
"000000147029/000001/000002"
"000000147029/000000/000001"
"000000147029/000000/000000"

Curious if the docs are wrong or whether this is a code bug.

EnriqueL8 commented 10 months ago

According to different sources including web3js states that logIndex: Number - integer of the log index position in the block. null when its pending log. which means that the behaviour is correct but the documentation seems wrong. Since Firefly has a pluggable architecture to support other blockchain protocols, this value might be different.

EnriqueL8 commented 10 months ago

Better source is the Ethereum documentation https://ethereum.org/en/developers/docs/apis/json-rpc which states the same logIndex: QUANTITY - integer of the log index position in the block. null when its pending log.

Coupling this with the transaction index allows a user to have a unique ID for an event.

hosie commented 10 months ago

Thanks @EnriqueL8 With that behaviour, the following statement from the docs would remain true, which is very important

**The string is alphanumerically sortable as a plain string;**
EnriqueL8 commented 3 months ago

Assign @dwertent to this one I add him to a triage group