Operation level from diagnostic_aggregator not consistent about diagnostics HOT 6 CLOSED

I really do not know that package that well, has the fix in issue 46 fixed it ? What would you recommend to track that down ?

from diagnostics.

No, issue #46 in rqt is not doing anything to tackle this (there I simply ignored the issue as the influence is minor to my system).

I can take a look at diagnostic_aggregator's code with lower priority (might be in January).

from diagnostics.

I am not very familiar with this part of the stack as well, I worked
more on the diagnostic_updater part. I've never encounter this problem,
but I must admit that I have never looked at it in great details either.
It'd be great if you could work on it. Try to contact the original
authors of the aggregator if you need information, they are may not be
watching the stack on github.
Brice

On 12/11/2012 09:05 AM, Isaac Saito wrote:

No, issue #46 in rqt is not doing anything to tackle this (there I
simple ignored the issue as it's minor for my purpose).

I can take a look at diagnostic_aggregator's code with lower priority
(might be in January).

—
Reply to this email directly or view it on GitHub
#4 (comment).

from diagnostics.

Thanks. I'll look into when I'm freer.

Just as an update, this might not that be rare case (so I removed "rare" from the title).

I'm seeing another similar output. http://pastebin.com/KMERQDVU
Top level status "/Computers" is 2 (ie. ERROR) but there's no ERROR state in its children. Only some STALEs.

from diagnostics.

This looks like an error because the /Devices/IMU is expecting 4 children, and only has three, so the error here in the parent is valid.

from diagnostics.

Makes sense. Thanks!

from diagnostics.