fix!: throw InvalidDataLengthError when input exceeds MAX_DATA_LENGTH

[acul71]

Description

Changes Made:

• Created a new constants.ts file:

  • Added a central location for storing constants like MAX_DATA_LENGTH and MAX_LENGTH_LENGTH.

• Modified decode.ts and encode.ts:

  • Both files now import constants from constants.ts, ensuring that the constants are defined only once and are accessible throughout the codebase.

• Added a check for MAX_DATA_LENGTH in encode.ts:

  • Implemented a validation in encode.ts to throw an InvalidDataLengthError if the input exceeds the defined MAX_DATA_LENGTH. This helps to avoid processing data that's too large.

• Added tests:

  • Created tests to verify that the validation correctly throws an error when input exceeds MAX_DATA_LENGTH.

Motivation:

This change improves maintainability by centralizing constant definitions in constants.ts. It also ensures that input validation for MAX_DATA_LENGTH and the custom maxDataLength is consistently applied and prevents potential issues when dealing with large data.

How to Test:

• Run the existing tests to ensure the functionality works as expected.
• Specifically, check that an error is thrown when the input data size exceeds MAX_DATA_LENGTH or the custom maxDataLength

Notes:

• The InvalidDataLengthError class has been utilized to handle cases where the data exceeds the maximum allowed length.
• Ensure that constants.ts is updated if the limits (e.g., MAX_DATA_LENGTH) need to change in the future.

[acul71]

@alanshaw @achingbrain

[acul71]

@achingbrain lint issue fixed.
Hope everything is right now!

[achingbrain]

LGTM. This should be released as a major since there's now a default max input length - it'll now throw in places it didn't previously.

[acul71]

@achingbrain In 8f31186 There are some comments so I can ask you questions:

it('should not encode message data that is too long PROMISE', async () => {
    const customMaxDataLength = MAX_DATA_LENGTH
    const input = new Uint8Array(customMaxDataLength + 1) // Create a buffer larger than the max allowed

    // Wrap in a Promise to ensure compatibility with async assertions
    await expect(
      Promise.resolve().then(() => lp.encode.single(input))
    ).to.eventually.be.rejected.with.property('code', 'ERR_MSG_DATA_TOO_LONG')
    // ).to.eventually.be.rejectedWith(InvalidDataLengthError).and.have.property('code', 'ERR_MSG_DATA_TOO_LONG')
  })

I tried to use the same matchers to be slightly more expressive, but I have to wrap encode.single in a promise, does it eventually make sense?

[SgtPooki]

@achingbrain In 8f31186 There are some comments so I can ask you questions:

it('should not encode message data that is too long PROMISE', async () => {
    const customMaxDataLength = MAX_DATA_LENGTH
    const input = new Uint8Array(customMaxDataLength + 1) // Create a buffer larger than the max allowed

    // Wrap in a Promise to ensure compatibility with async assertions
    await expect(
      Promise.resolve().then(() => lp.encode.single(input))
    ).to.eventually.be.rejected.with.property('code', 'ERR_MSG_DATA_TOO_LONG')
    // ).to.eventually.be.rejectedWith(InvalidDataLengthError).and.have.property('code', 'ERR_MSG_DATA_TOO_LONG')
  })

I tried to use the same matchers to be slightly more expressive, but I have to wrap encode.single in a promise, does it eventually make sense?

There is an example of the pattern you should be able to use at https://github.com/libp2p/js-libp2p/blob/31a15a1483e0af0f9ede24de0a7f1d24bf9d408d/packages/kad-dht/test/record/selection.spec.ts#L19-L23

basically you can expect .to.throw() with whichever properties

[acul71]

@SgtPooki @achingbrain Should be ready with enhanced test assertions with expressive matchers

[SgtPooki]

cc @alanshaw I don't have access to this repo and Alex is out this week

[github-actions]

🎉 This PR is included in version 10.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀