Skip to content

False unshielded inclusion when earlier batch tx is invalid/not included #94

@ylembachar

Description

@ylembachar

Observer can mislabel a tx as unshielded inclusion even when it was included in the correct slot.

Root cause:

  • Expected position is local loop index (for index, txSubEvent := range txSubEvents)
  • It is compared to receipt block index (receipt.TransactionIndex)
  • If an earlier tx in the same batch is invalid/not included, later tx shifts position and gets flagged unshielded

Code:
https://github.com/shutter-network/observer/blob/main/internal/metrics/tx_mapper_db.go#L402
https://github.com/shutter-network/observer/blob/main/internal/metrics/tx_mapper_db.go#L544

Example:

  • Slot 26733706, batch pointer 384
  • Tx 384 (0x1afbffda9a2a08ca059a58872409285f96ea8ec53d7fa7b672bb4318d45c550a) -> not included, receipt null
  • Tx 385 (0xf6db394e45b3e7212a9d3683a3cdaf20af1b2936a8775a8d00d2ec33ad1c9115) -> receipt status=1, included in slot 26733706, receipt index 0
  • Observer local index for tx 385 is 1 -> marked unshielded inclusion only due to index mismatch

Expected:

  • If slot matches, this should be treated as shielded if the transaction is invalid.
  • Also useful: persist a reason field for not included to simplify debugging.

Additional info:
In this specific case, we are not sure the tx at 384 is invalid, but the code shows this is not taken into account

Reference spec: #46
valid_tx_list = filter(not_invalid_and_not_not_decrypted, tx_list)

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions