Skip to content

Conversation

@linouxis9
Copy link
Contributor

Depends on #17

WIP, unit tests to be fixed.

@linouxis9 linouxis9 marked this pull request as ready for review March 27, 2024 10:54
@linouxis9
Copy link
Contributor Author

@wmnsk
Issues found with units tests were fixed.
Thanks! :-)

Copy link
Owner

@wmnsk wmnsk left a comment

Choose a reason for hiding this comment

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

Can you provide the example of payload that this PR will make it possible to handle? 💯 if you can add it to the test case in codec_test.go.

What is the point in returning "Decoded Length is not equal to..." error? In which situation would it happen, and can it be avoided somehow?

@linouxis9
Copy link
Contributor Author

linouxis9 commented Apr 1, 2024

Can you provide the example of payload that this PR will make it possible to handle? 💯 if you can add it to the test case in codec_test.go.

Yes, I'll add an example as a test case! But basically it allows you to construct a tree of IEs (IEs containing other IEs) and then marshaling them, without having to manually inject the inner IEs encoded into the outer IEs's Value field.
It's pretty handy to construct a TCAP with a MAP payload out of tcap.IE for instance.

What is the point in returning "Decoded Length is not equal to..." error? In which situation would it happen, and can it be avoided somehow?
There are two cases where this error can be triggered:

  • Internal parsing issue where the IEs were incorrectly decoded: while developing this PR, some times, I mistakenly decoded multi IEs into a single IE with some fields being lost, this helped catching the issue
  • The message being parsed is invalid, for example: the IE TLV's length is not equal to the size of its child IEs + the headers: this helped me caught a few marshaling issues when trying to unmarshal a message marshaled with go-tcap.

This error helped me while developing this PR, and I'm sure it could help us catch parsing errors in the wild, and could make potentiel bug reports a bit more readable of what happened in case of issues.

Thanks a lot for your time on such a niche but awesome library :-)

@linouxis9
Copy link
Contributor Author

linouxis9 commented Apr 4, 2024

Test case added and rebased upon new commit of PR #17, thanks a lot!

@linouxis9
Copy link
Contributor Author

Hey @wmnsk,
I hope you are doing well!
Do you think this is something that could be merged?
Thanks a lot!
Valentin

@wmnsk
Copy link
Owner

wmnsk commented Jun 24, 2025

doh I missed it due to the chaotic post vacation situation 🤦 looks good at a glance, but let me review it again sometime soon this week. Thanks for your patience!

Copy link
Owner

@wmnsk wmnsk left a comment

Choose a reason for hiding this comment

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

Great work overall, could you check minor comments on the error descriptions?


c.SetLength()
if b[1] != c.Length {
return fmt.Errorf("decoded Length is not equal to Components Length, got %d, expected %d", c.Length, b[1])
Copy link
Owner

Choose a reason for hiding this comment

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

I'm not a fan of log-like (redundant) error message - what about this? Or maybe we can even define a custom error like LengthMismatchError with some useful fields, but that's perhaps a bit overkill.

Suggested change
return fmt.Errorf("decoded Length is not equal to Components Length, got %d, expected %d", c.Length, b[1])
return fmt.Errorf("component length mismatch, got %d, expected %d", c.Length, b[1])


c.SetLength()
if expectedLength != c.Length {
return fmt.Errorf("decoded Length is not equal to Component Length, got %d, expected %d", c.Length, b[1])
Copy link
Owner

Choose a reason for hiding this comment

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

Same here.
Also, nicer to have expectedLength in `Components above as well?

}
// Dialogue is not a Transaction Payload
// We have to remove Dialogue from the Payload
// Or mashaling an unmarshaled message will write back two times the Dialogue
Copy link
Owner

Choose a reason for hiding this comment

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

Suggested change
// Or mashaling an unmarshaled message will write back two times the Dialogue
// Or marshaling an unmarshaled message will write back two times the Dialogue

@wmnsk wmnsk deleted the branch wmnsk:master January 5, 2026 10:08
@wmnsk wmnsk closed this Jan 5, 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