Skip to content

Conversation

@constantinius
Copy link
Contributor

No description provided.

Copy link
Owner

@donmccurdy donmccurdy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @constantinius!

Comment on lines +88 to +99
test('zstddec-stream: decode without init should throw error', async (t) => {
const zstd = new ZSTDDecoder();

try {
zstd.decode(HELLO_WORLD_ZSTD);
// If we get here, the implementation doesn't throw - test behavior as-is
t.pass('decode works without explicit init (auto-initializes or uses shared instance)');
} catch (err) {
t.ok(err.message.includes('Await .init() before decoding'), 'throws error when decode called before init');
}
t.end();
});
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not blocking but I don't think I understand this case - shouldn't this consistently either throw, or not?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, we have a global init promise, which, if not settled, raises an exception. Which is kind of hard to test.

@donmccurdy donmccurdy merged commit 760df47 into donmccurdy:main Jan 8, 2026
1 check passed
} catch (err) {
// If it throws, that's also acceptable behavior
t.ok(err.message.includes('Incomplete stream') || err.message.length > 0, 'throws error for incomplete stream with no data');
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, I think I may change this to enforce one behavior or the other. Not that I have a strong preference, but would like to know if the behavior changed, and the test can ensure that. Unless there was some reason to include both?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, good question, I agree, we should only include the first, I think

@donmccurdy donmccurdy mentioned this pull request Jan 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants