Assigning a (L1?) tx which has no data breaks a process

[keikari]

Few example txids which will break a process when assigned. All have no data and are L1 txs. (L1 txs which have data worked fine)

ZIMDxVbQ86brHqPRwX8poaXozT9sf0bJYeAyJtz1BGg
qrU8GoJ6y4KWwUvOzipPZxAg3UNbFQyjwytWhFtCROM
elF56xgXlrs2HfuOwxc-OQKBzxRuyNlnCTQnb8_i2jc

Gives error like:

"Error encountered when fetching transaction 'ZIMDxVbQ86brHqPRwX8poaXozT9sf0bJYeAyJtz1BGg' from arweave: 404: Not Found"

Error will happen with all messages following the assignment, making the process unusable.

https://cu.ao-testnet.xyz/result/yiZ3Q-6xaoSQyzM5pjr5tcxnwGm94G4FPl9P4pNxuGc?process-id=tpr9h6N0rY-wojVFnPQ_nyz3Kip16Wd4Az9yUbctIj8

[TillaTheHun0]

ZIMDxVbQ86brHqPRwX8poaXozT9sf0bJYeAyJtz1BGg does indeed come back from Arweave as not found. The SU should not have assigned the tx, if it could not attest to it's existence on Arweave.

Currently, in cases where the CU is not able to fetch the assigned transaction from Arweave, the implementation fails fast, not evaluating any further. This is to prevent non-determinism, potentially due to network issues, from being exposed to the ao process. Subsequently, in situations where a tx will never be resolved from Arweave, this could "brick" a process.

We need to figure out a bonafide, consistent, and reliable signal, for the CU to use in these cases; there isn't a clear way to determine a network error to mean "this transaction couldn't be fetched -- try again later" and "this transaction will never exist -- skip and continue evaluating", hence the current fail-fast behavior. Even more kosher would be a way to determine "this tx didn't exist, as the point of assignment by the SU" as attestation of the data on Arweave is the SU's responsibility, and could constitute slashing, if incorrectly attested.