diameter: modify diameter_traffic:pick_peer/4 to be able to handle requests of type: #diameter_packet{}

[anupamasingh10]

In case of requests in the format of #diameter_packet{}, pick_peer functionality is working incorrectly as the current implementation cannot find Destination-Host in the request. Added a clause to handle #diameter_packet.

[github-actions]

CT Test Results

  2 files   34 suites   14m 3s ⏱️
131 tests 128 ✅ 3 💤 0 ❌
159 runs  156 ✅ 3 💤 0 ❌

Results for commit 816a68b.

♻️ This comment has been updated with latest results.

To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass.

See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally.

Artifacts

• Complete CT logs (Download Logs)
• HTML Documentation (Download HTML Docs)
• Windows Installer

// Erlang/OTP Github Action Bot

[bmk]

This was based on maint. Was this because you wanted this to be a 26-patch? Or is ok OK to rebase on master?

[sebastiw]

preferably 26-patch

[bmk]

Will be released in 27.0 (merged to master) and eventually in 26.2.6

[RoadRunnr]

The unit tests passes a #diameter_packet as 3rd argument to diameter:call/4. According to the documentation https://www.erlang.org/doc/man/diameter#call-4, that is not an allowed value for that argument.

So, either the documentation is wrong, then a fix for that should be included in this PR as well, or the documentation is correct and passing a diameter_packet record is not permitted in the first place and no change would be needed.

[bmk]

For master (27) that argument is now documented as 'any()'.
But I noticed this also, so for the 26 patch (at least) it needs to be updated.

[RoadRunnr]

For master (27) that argument is now documented as 'any()'.

That seems to be an effect of using the new documentation tool chain and not necessarily a conscious decision to accept any term as message. It seems the documentation even lost every description of what is acceptable as Request.

To me it actually looks like as if changing the documentation of the Request argument from diameter_codec:message() to any() is the bug here. The description of diameter_code:message() even seems to suggest that this is the only type accepted by call/4.

In any case, if indeed the intended type of the Request argument is diameter_codec:message() | diameter_codec:packet() , would it be possible to adjust the OTP-27 documentation accordingly?

[bmk]

I looked at the 26 code and according to the diameter:call/4 spec, the third argument
is typed as 'any()'. So, regardless of the documentation, the type is actually 'any()'.
It looks like we need to review the diameter documentation after the (27.0) release.,,