Transient API key length could result in uncacheable data

[archon810]

I was just writing a caching layer for some plugin code using the Transient API and found that while caching was created, it was immediately discarded and re-cached. Upon further examination, I found that the transient key was different for the data itself compared to the timeout key. Specifically, the transient timeout key was longer due to the presence of the word "timeout" in it and was running into the MySQL key length limit of 64 characters, getting silently truncated.

Therefore, the key for the timeout was different than the key for the data, resulting in both rows being deleted every time get_transient() is called.

A solution would involve checking for the key length and possibly truncating the data key so that it wouldn't truncate the timeout key, but this solution could be confusing to the plugin writer who is expecting a certain key.

Sorry if I was confusing in describing the bug. tl;dr: transient key and transient timeout could end up being different and prevent caching from working.

[solarissmoke]

Replying to archon810:

Specifically, the transient timeout key was longer due to the presence of the word "timeout" in it and was running into the MySQL key length limit of 64 characters, getting silently truncated.

Doesn't get truncated - WP_DB just bails and issues an error notice:

WordPress database error Data too long for column 'option_name' at row 1 for query INSERT INTO `wp_options`...

and set_transient() also returns false telling you that something went wrong. IMHO this is sufficient warning? We can't truncate keys because the user will still be looking for they key they asked to set.

[nacin]

#15058