[amiga386]

Yeah but don't let them reify it.

Ideally you already send client version in requests (or have an API version prefix). Add the workaround only for legacy clients.

Next client version must distinguish itself from predecessor and must not require the bodge to work.

[mainde]

Well.. it was ~6 years and ~10 billion payments ago, the clients have been fixed but the "hack" is still there, it has caused no harm as far as I can tell. Worst case scenario it's useless, best case scenario it prevents regressions.

The issue with things that client must not do is that they might still do them, and users don't care whose fault it is. It's important to have auxilliary mechanisms to mitigate these.

[amiga386]

That it may be there or not doesn't mean it "caused no harm". It sounds like yet another carbuncle added in haste and then never fixed properly, leading to 6 years of fear of touching it.

If it's truly intended, it needs to be part of the official spec, with a robust justification of why it's there at all. Neither server nor client ought to have unnecessary and undocumented things "just in case", because that breeds a culture of uncertainty.

If you fear client regressions, make it a mandatory part of the client's test suite. You control the client, right?