MySQL chain replication timing of writes on first slave
To answer this, you need to understand the way MySQL replication works and the difference between the IO_thread and the SQL_thread.

In a nutshell, the IO_thread pulls events from the master and stores in the relay_log. The SQL_thread pulls from the relay_log and applies them to the slave dataset.

So, the description of --log-slave-updates (emphasis mine):


  This option causes the slave to write the updates performed by its SQL thread to its own binary log


means that the MySQL is only logging to the first slave's binary log after it is being committed on that slave. And it won't be available to the second slave until it has been committed on the first slave.

So if I'm understanding you right, you should be safe in your us-ecase.



Single-threaded sql thread and slave lag

It is important to note that by default, the SQL thread is single-threaded. This means even though your master can apply changes across multiple connections very quickly, when it is applied to the first slave it is one change at a time. This can contribute to slave lag. 

Luckily, in MySQL 5.6 the ability to have multiple slave thread appliers was introduced with the --slave-parallel-workers option. 

However, this only helped if you had multiple schemas(databases), because MySQL would only apply in parallel if statements were in different schemas.

This limitation was removed in 5.7 to allow for parallel application within the same schema.

The main point I am trying to make, is that if you are dealing with slave lag on the first slave, the second slave will take similar time (assuming similar hardware) so will be even further behind your master. So ensure your custom application takes that into account.