DASL Testing: Tier 1

[makew0rld]

Hello,

I work on DASL Testing, a project funded by IPFS to test dag-cbor libraries.

I'm filing this issue to report on "Tier 1" bugs we've discovered in python-libipld. More information is available here.

Please feel free to use this issue for tracking bug fixes, asking me questions, or anything else that's helpful.

Bugs

• The smallest CBOR integer, $-(2^{64})$ or 3bffffffffffffffff is converted to 00 (zero)

I'd also like to mention that this library sometimes raises PanicException from pyo3, which can't be caught the normal Python way of except Exception, instead I have to do:

    except BaseException as e:
        if type(e).__name__ == "PanicException":

Ideally this library would not raise PanicException, even for invalid input.

---

You can view all the tests in more detail on the DASL testing website: https://hyphacoop.github.io/dasl-testing/

[MarshalX]

Hi, the smallest CBOR integer should be fixed in #58. Thank you!

@makew0rld your testing website say that this lib also fails to handle the largest CBOR integer But I can not reproduce it. Could you pls explain this?

[makew0rld]

Hi, the smallest CBOR integer should be fixed in #58. Thank you!

Nice, thanks! Feel free to close this issue once that is merge/released.

As for the largest integer, I didn't report that because your library provides an error rather than silently changing the value. Note this is a roundtrip test, so to reproduce it you have to decode and then encode the value. For example:

❯ python
Python 3.13.3 (main, Apr  9 2025, 07:44:25) [GCC 14.2.1 20250207] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import libipld
>>> libipld.decode_dag_cbor(bytes.fromhex("1bffffffffffffffff"))
18446744073709551615
>>> libipld.encode_dag_cbor(18446744073709551615)
Traceback (most recent call last):
  File "<python-input-2>", line 1, in <module>
    libipld.encode_dag_cbor(18446744073709551615)
    ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
ValueError: Failed to encode DAG-CBOR. OverflowError: Python int too large to convert to C long
>>>

If you're interested in fixing this that would be great too, but we're not considering it part of Tier 1.

[MarshalX]

@makew0rld awesome! I have fixed it as well in the same PR.

Speaking of panics, I fixed the one about invalid UTF-8 (#59). Do you maybe have a list of tests where lib panics? It would be incredibly helpful

[makew0rld]

Good to hear!

I added some prints to my test suite and found only one other occasion when a panic occurs: trying to encode a map with an integer key. It's correct for this to cause an error, but it shouldn't be a panic.

[MarshalX]

@makew0rld amazing, thank you! and sorry for being too lazy to run your tests locally to add this print statement around panics :)

here is the summary of PRs related to this ticket:

• Fix smallest and largest CBOR integer roundtrip #58
• Fix panic on non UTF-8 string #59
• Fix panic on encoding map with integer keys #60

tl;dr int fixes; panic fixes

The issue will be closed automatically after the merge, but I will ping you when new release will happen and you can rerun your test suite. Thanks a lot!

[makew0rld]

Awesome, thanks! The test suite should automatically update once you publish a new release on PyPI, it checks daily. But feel free to ping me if there's any issues.

In the future I'll file a Tier 2 issue for the next round of bugs, if there are any. Great working with you!

[MarshalX]

Thank you! The v3.1.0 release is on PyPI! I will wait for the CI to update the website.

I ve included 2 more fixes to the release from other tiers:

• Fix decoding of infinities and NaNs according to specs #62
• Fix handling of concatenated objects / CBOR sequence #65

should be at least +6 passed tests

[MarshalX]

Update the deps workflow works well by cron, but produced automated commit will not trigger the build pages workflow. Because GitHub prevents triggering one workflow from another one to prevent loop abuses.

In my own repos I fixed it by providing personal access token instead of temporary generated for GHA run. That will allow to trigger on push workflow. I passed my PAT actions/checkout step

[makew0rld]

Fixed, thanks. I see the tests passing now. Really appreciate the quick turnaround on this!

[makew0rld]

@MarshalX I noticed a regression that is still considered Tier 1. libipld now doesn't raise an error when the user tries to encode a bignum. It looks like I might not have a input test for big num yet, but that should raise an error too. I assume this is a side effect of changing to i128 in #58.

[MarshalX]

@makew0rld thank you! i ve noticed this as well. i did a fix in #66