Loop in WSJT-X when using non-standard callsigns - QSO not possible

Last year, while working FT8 with DL0NGCAT I came across some strange behaviour of FT8.

If you use "long" event callsign (over 6 letters, like DL0NGCAT, DF4CEPALM), you will be called by other non-standard callsigns (like DB4SCW/P, DL0LOL/QRP, 9A/DO4SCW, or PD33ZDOGE).

Problem: A QSO with two non-standard callsigns is not possible with WSJT-X, because with two such long callsigns the bits within a WSJT-X message are not sufficient to transmit ANY other information outside the two callsigns.

WSJT-X will not tell you this. It will continue to create the messages including Rapport, RR, RR73 or 73 and it will try to answer your caller.

Unfortunately, because the message is too long for FT8, it will only send both callsigns and omit all other information. This is what it looks like:

decode No. content description
0 ... You keep doing your FT8 thing...
1 CQ DF4CEPALM JN49 and then call CQ...
2 <DF4CEPALM> PD33ZDOGE another non-standard call answers...
3 PD33ZDOGE <DF4CEPALM> your WSJT-X tries to answer, but truncates the Rapport...
4 <DF4CEPALM> PD33ZDOGE your callers WSJT-X does the same ...
5 PD33ZDOGE <DF4CEPALM> your WSJT-X again...
6 <DF4CEPALM> PD33ZDOGE ... their WSJT-X again and now we enter into a loop...
7 ... ... which continues as long as both OPs do not abort.

You see that both WSJT-X programms just continue to shout each others callsign at each other, as long as neither OP stops the loop.

A simple error message while generating the messages explaining the bit-limit of the FT8-Protocoll would provide sufficient information. But for some reason WSJT-X does not do this, but (see table above Decode 2-6) will continue to produce and transmit nonsense (!!!) until an OP (either the QSO partner or you yourself) intervenes and aborts.

There is nothing that you as an OP can do - FT8 simply does not allow to complete a QSO between 2 non-standard calls. You have been warned and you know why.

Have fun on the air!

73, DE Stefan, DB4SCW