Bitcoin nodes don't answer `getheaders` with `headers` anymore?

[btcnbegun]

Just asking for a short answer about BIP152

Completing handshakes and sending getheaders messages to other bitcoin nodes. Here's the debug output:

Connection established successfully with

User Agent: /Satoshi:25.0.0/

What do you want to do?
1. ask for genesis block headers

1
Requesting for block headers...
Sending getheaders, see payload (69 bytes):
7e110100016fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d61900000000004860e b18bf1b1620e37e9490fc8a427514416fd75159ab86688e9a8300000000
[DEBUG]: Received sendcmpct, see payload (9 bytes):
000200000000000000
error: PayloadParseError
C:\projectpath\src\network.zig:445:37: 0x7ff7f39b7949 in parse (zig-bitcoin.exe.obj)
            if (!supported_command) return error.UnsupportedCommandReceived;
                                    ^

Don't mind the error, it just means that it doesn't have code to handle a sendcmpct command. Confusion arises cause apparently sendcmpct is asking for blocks, when the sys was the one asking first let's have some order here.

NOTE: The node being reached by me in IP[STATIC] is on the seeding of hardcoded nodes of bitcoin core

[pooya87]

Handshake between nodes is more than just sending version/verack messages back and forth. It consists of sending and receiving a couple of other messages that I'd like to call "preference" messages which are telling the other peer the settings and preferences your node prefers.

These messages include feefilter, sendcmpct and sendheaders. They need to be handled during handshake and the receiver needs to remember these preferences so that it can communicate with its peer the way it requests.
For example when receiving sendcmpct "preference" message, the receiver has to remember to send any new blocks to this peer as compact blocks as defined by BIP-152.

Assuming this is the code, the reason why it is crashing here is because it lacks the message parsing capability not because the other node responded to getheaders with sendcmpct. It probably got caught in the parsing queue and crashed there.
I say "queue" because these messages aren't necessarily sent one by one, they can be received in one payload (eg. verack + ping + feefilter + sendcmpct) and the receiver has to handle the entire payload with multiple messages.