What's up with this transaction version being not a signed integer?

Hey, so I was looking at transaction 5839f20446d7b9446e82c00117ee3699fa84154e970d57f09add60deef2eaa18 on the bitcoin testnet, and my node's RPC shows the transaction version as 4294967295 (which is 0xFFFFFFFF). But according to the docs, this should actually be a signed integer of 4 bytes. This implementation I found also says the same thing and even suggests that transactions with that version won’t be relayed by the network, even though they still show up in blocks! I’m really confused as to why the RPC is returning this version as an unsigned number instead of -1 like it should. Is this some kind of error with the bitcoin RPC serializer?

It's complicated. The version number is stored as a signed integer. However, in every single place that it is being used, including in consensus code, it is being cast to an unsigned integer. So the RPC also does that since it's only ever actually interpreted as an unsigned int. It probably should just be changed to an unsigned integer, but I think there was some discussion about that and there were fears that there may be some unintended side effects. Since it is consensus critical code, it could lead to consensus failure if something was overlooked.