Oh, yes, that is binlog row being pendantic. There may be a temporary way to disable that behaviour. Let's start by converting all masters and slaves, we will see how to handle it- worse case scenario, we can do the changes manually from the statement binlog.

I have reproduced the error on a test vm and looks like the following mode fixes it. And the information looks sane and not broken:

set global slave_type_conversions = "ALL_NON_LOSSY";

From the doc:

This mode permits conversions that do not require truncation or other special handling of the source value; that is, it permits conversions where the target type has a wider range than the source type.
Setting this mode has no bearing on whether lossy conversions are permitted; this is controlled with the ALL_LOSSY mode. If only ALL_NON_LOSSY is set, but not ALL_LOSSY, then attempting a conversion that would result in the loss of data (such as INT to TINYINT, or CHAR(25) to VARCHAR(20)) causes the slave to stop with an error.

codfw is only pending the master. I will do it once I am done with eqiad hosts (which I have started already). It will generate lag on the whole codfw datacenter for 2-3 hours the alter lasts on not so powerful servers.

The last host of eqiad (apart from the primary master) is now running the alter.
Once it is done, I will alter codfw master, so it will create lag in the whole codfw for a couple of hours, till the columns get modified. I will silence the hosts but they will be "red" in tendril /cc @jcrespo
This way once we have switched the DC we can modify the columns in eqiad master and get this ticket over with