PublishQueueExt (CloudEvent API) corrupt/not sending events, but Particle.publish does

Firmware Libraries
1

Dear all,

Title says most - I have some findings in the github issue here as well:

For some reason, my events are not going through when CloudEvents are sent using the ParticlePublishExtRK library (latested version from May being used), but sending exactly same event with Particle.publish works perfectly. I suspect something is getting corrupted, as events either are not being sent (when I attach .data) or when I only send an event without .data, it comes back as

{"content-type":0,"name":"tev"}X��U�

on Particle Console (event stream).

Where using PublishQueueExt will keep retrying the CoAP until it fails and the queue will start to build up.

2

What overload are you using to publish the data?

3

I've tried both the VariantMap overload and the CloudEvent overload (which is the one I'm currently comparing normal Particle.publish to PublishQueueExt atm)

4

I think there is a bug if you pass a cloud event with no data, I'll take a look later today.

1 Like
5

Let me know if I should test something, I'm focusing on this for the remainder of Today.

6

I'm not positive this is the bug you are seeing, but it may fix the problem.

0.0.7 (2025-05-12)

  • Fixed bug when you have no event data.
  • Fixed a bug when non-structured, non-variant events could have garbage data at the end of the event data.
1 Like
7

Thank you for responding so quickly @rickkas7 - I've just update the library code and it looks like it's working now and I'm getting well-structured JSON on Particle Console. I'll test some more, roll it out on our test units in the field for a larger scale test.

1 Like
8

I've run into another issue, after updating units with the PublishQueuePosix library to the PublishQueueExt library - my watchdog is getting triggered, as the device freezes around calling:

PublishQueueExt::instance().publish(measurementEvent);

Only suspect I can find, is the checkQueueLimits being called from the publish(CloudEvent cv) function, that has a while loop:

void PublishQueueExt::checkQueueLimits() {
    WITH_LOCK(*this) {
        while(fileQueue.getQueueLen() > (int)fileQueueSize) {
            int fileNum = fileQueue.removeSecondFileInQueue();
            if (fileNum) {
                fileQueue.removeFileNum(fileNum, false);
                _log.info("discarded event %d", fileNum);
            }
            else {
                break;
            }
        }
    }
}
9

Those locks are unnecessary because there's already a lock in the SequentialFileRK library. I don't see exactly the sequence of events that occurs that causes it to deadlock, but the locks aren't necessary so there's no reason to have them.

0.0.8 (2025-05-20)

  • Removed unnecessary lock that could cause deadlock.
1 Like
10

It seems as if it's related to the while loop in the checkQueueLimits when I've updated firmware that has earlier used PublishQueuePosix to PublishQueueExt - I'll see what is going on

11

I don't see how that loop can fail to exit, but I added a limit to the number of times it loops just in case.

0.0.9 (2205-05-22)

  • Added a limit to the number of files to remove from the queue on checkQueueLimits
1 Like
12

I've tested on three devices and it seems like they're all three restarted by the hardware watchdog after 10 min during the publish call in the PublishQueueExt, but at random places in the function (bool PublishQueueExt::publish(CloudEvent event)). I've logged the last line being executed before the watchdog timer and it's different each time.

I'm going into the field Tomorrow to see the logs about what's happening, it could be that it's simply looped publish that it may never exit from - whether that's happening due to some corrupt files or so on Flash or bad state, I'm unsure.

I'll investigate some more and get back.