I realize you may hope someone just has “the answer” for you (I don’t), but barring that I do have some diagnostics to recommend.
First, you’re wondering if perhaps “something changed in 5.3.8”, since it works in prod on 5.3.7 but fails on 5.3.8 in dev. While you await anyone clarifying that about this, you could prove/disprove that by running 5.3.7 in dev. But I realize that may be “not an option”, so I’ll continue.
Second, as you may know, the purpose of objectload is to deserialize some object that was persisted using objectsave. If the object may have been saved with one Lucee version and is being loaded with another, perhaps that could be an issue. I’ll leave that for Lucee engineers to speak to.
Finally, consider also dropping to traditional debugging, and do a cfdump/dump of each part of the elements holding that variable being passed to the function. Even if you may think, “I don’t know what they should look like”, just doing the dump may show an error or unusual result for one of them.
I do see you said “there is data in the column being retrieved / used here”, so maybe you did this already. FWIW I don’t see a “column” being referenced, but maybe you mean that the
local.st[local.i].associatedObject is known by you to represent a db col.
In any case, does dumping it show it to be xml, specifically in wddx format, which that getDataWDDX() function you use would be wanting to parse? If it’s not, then dump each var to the left of it in that complex var.
And of course, I do mean you should do the dump BEFORE doing the tobinary. You quipped that you don’t read it, and fortunately you should not need to.
And if somehow you’re still stuck seeing what’s amiss at this point, you could do the same dumps in prod on 5.3.7 (preferably with the same or similar data), that may show you what things SHOULD look like, which could be useful for comparison, if it’s at all an option.
As for “what changed” to cause the error, maybe the info you find will give you/us a new clue.