Assigning a (L1?) tx which has no data breaks a process about ao HOT 1 OPEN

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.

from ao.