Indexer contradicts docs: cenotaph flaw shown as etching

[ASuciuX]

According to the docs, a runestone with Flaw:TruncatedField should not produce a cenotaph etching.

However, the indexer displays it as an etching here: DONALDJOHNTRUMP rune.

I added a unit test to illustrate the issue: PR #4402.

Does anyone know the reasoning behind this discrepancy?

[ASuciuX]

@raphjaph @casey thanks for all your work! When you have a moment, could you please take a look and let me know if there’s anything specific that causes this behavior and how should this be treated? In the codebase the Flaw:TruncatedField has priority over Flaw:UnrecognizedEvenTag.

[casey]

Thanks for the unit test! It makes it easy to see what's going on.

Flaw::TruncatedField is produced when a tag is not followed by a value, i.e., when a tag other than the body tag is the last value in the &[u128] payload:

      let Some(&value) = payload.get(i + 1) else {
        flaw.get_or_insert(Flaw::TruncatedField);
        break;
      };

The docs refer to a different issue:

If a LEB128 varint contains more than 18 bytes, would overflow a u128, or is truncated,
meaning that the end of the payload buffer is reached before encountering a byte with
the continuation bit not set, the decoded runestone is a cenotaph with no etching, mint,
or edicts.

This is referring to Flaw::Varint, which is a lower-level flaw when the payload of varints cannot be decoded.

Since Runestone::integers is returning successfully, the issue is not Flaw::Varint, which would result in no integers being decoded.

Looking at the decoded integers, they are: [2, 3, 4, 296598585583552681509, 1, 0, 3, 544, 5, 8376, 6, 20974368, 1000, 8, 21000]

There is no body tag, and there is an odd number of integers, so 21000 is a tag with no value, so it produces Flaw::TruncatedField, which does produce a cenotaph with an etching.

[ASuciuX]

Thanks for clarifying! The wording confused me.