The failed WS2812 pixel remains defunct:
Attach scope probes to its data input and output pins (with the fixture face-down on the bench):
The output no longer comes from the Land of Digital Signals:
I immediately thought the broken bits occupied the first 24 bit times, when the WS2812 controller should be absorbing those bits from the incoming stream. The vertical cursors show the failed bits occupy 54 µs = 40-ish bit times at 800 kHz (or you can count them), so it’s worse than a simple logic failure.
A closer look:
At least for those bits, neither output transistor works well at all. On the other paw, the output shouldn’t even be enabled for the first 24 bits, so there’s that to consider.
Lo and behold, it also fails the Josh Sharpie Test:
You may recall it passed the leak test shortly before I assembled the test array a month ago. Evidently, just few days of operation suffices to wreck the seal, let air / moisture into the package, and kill the controller. Not a problem you’d find during a production-line test (assuming there is such a thing), but it should certain appear during the initial design & production qualification test phase (another assumption).
Weirdly, a day after taking that photo, the controller began working perfectly again and the LEDs look just like they should: there is no explaining that!
The Smell of Molten Projects in the Morning 
You should try ‘resealing’ a batch and test vs. an unsealed control batch. Would be interesting. Or run a batch in a nitrogen atmosphere. Or… oops, I’m overdoing it again. ;-)
I’ll stick the scope probes into that thing if it’s still running in a few days: maybe the data output transistors have healed themselves, too. Weird!
Not really. Nice Chinese seller you bought them from reads your blog so he knew you had a problem. Instead of risking less then 5 star review he snuck in Basement Laborotory QC Wing during the night and swapped the bad units with replacements :)
That kind of customer service would guarantee a five-star review!
OK, dusting off failure analysis experience. I’ve seen similar failures when silicone goober has poor sealing, and moisture can set up a leakage path between inconvenient points. A well designed chip should be resistant to leakage from pad to where-ever, but if the top passivation layer isn’t very good, sensitive portions of the chip can be disrupted.
One decent test for this is to bake (unpowered) the parts for a day or two. If the part recovers, it was most likely leakage. You can have confounding issues from contaminants brought in with the moisture, not to mention what’s in Sharpie ink. [grin] I don’t have the data sheet any more, but I’d say well below the max storage temp. Max operating ambient temp should be OK, or 10-20C below that.
Less probably intermittent failures can be from flaky wire bonds or a really bad fabrication process. I’d put my money on leakage, though.
Nope, not going there, no how, no way. [grin]
When I moved it to workbench for probing, it failed again: whatever’s wrong inside that package isn’t reliably broken!
I wonder how they would do if you floated some sealant of some sort over the top of the device. Castable silicone or clear epoxy strike me as options. Is this the only cause of failure? The question I really have is, is the opening of the seal the cause or the effect?
The array started out with OK sealing, then one LED failed and showed a bad seal after a few days. I haven’t re-Sharpied the rest of the array.
The failed LEDs from various tubes / bulbs / whatever aren’t consistent: some have good seals, others bad, and most were untested. The fact that the LED encapsulant seal should never go bad suggests they’re using the wrong silicone goop (shades of the capacitor plague), mixing it badly, applying it poorly, or something along those lines.
The wire bonds look OK, to my untutuored eye, and there’s nothing else obviously wrong.