FUOTA ENQUEUE does not wait for mc msg's but instantly goes to FRAG_STATUS

Question

Hello,

I noticed that when all messages are enqueued, the task is done instantly.
Normally this will work for small FUOTA payloads or if the "Expected uplink interval (secs)" X "Unicast retry count (max)" is bigger then the time it needs to upload all the multicast message.

I think it would be nice if the ENQUEUE waits for all mc msg to be send.

Expected uplink interval (secs) = 4min

> FUOTA Job Status: job=ENQUEUE, created_at=2025-10-21 12:43:42, completed_at=None, attempts=0/1, sched=2025-10-21 12:47:42
> FUOTA Job Status: job=ENQUEUE, created_at=2025-10-21 12:43:42, completed_at=None, attempts=0/1, sched=2025-10-21 12:47:44
## Should wait here for all multicast msg to be send. but continues to FRAG_STATUS
> FUOTA Job Status: job=FRAG_STATUS, created_at=2025-10-21 12:47:43, completed_at=None, attempts=0/1, sched=2025-10-21 12:47:43
> FUOTA Job Status: job=FRAG_STATUS, created_at=2025-10-21 12:47:43, completed_at=None, attempts=1/1, sched=2025-10-21 12:51:44

  application_id: "..."
  device_profile_id: "..."
  name: "TEST-Maurits"
  multicast_dr: 5
  multicast_frequency: 869525000
  calculate_multicast_timeout: true
  unicast_max_retry_count: 1
  calculate_fragmentation_fragment_size: true
  fragmentation_redundancy_percentage: 10
  fragmentation_descriptor: "BEEF"
  request_fragmentation_session_status: AFTER_FRAGMENT_ENQUEUE
  payload: "..."
  on_complete_set_device_tags {
    key: "test_tag"
    value: "test_value"
  }
}```

Chirpstack: 4.13.0 (docker image)

Maurits Meeusen · Accepted Answer

i changed request_fragmentation_session_status = AFTER_FRAGMENT_ENQUEUE to AFTER_SESSION_TIMEOUT, that was the behavior i was looking for.

i guess i was looking for the behavior of AckReception.

Orne Brocaar · Answer

I think it would be nice if the ENQUEUE waits for all mc msg to be send.

A job runs and finishes or re-tries, it does not sleep or wait. The enqueue finishes directly, because it will immediately enqueue all fragments to the multicast queue. While it does schedule the FRAG_STATUS job, it does schedule it in the future.

This was made more clear in this change (part of v4.13.0):

Make it more clear if FUOTA job is running or if it is schedule: https://github.com/chirpstack/chirpstack/commit/2565cca14ae7bfcf194a7c9cebeb530d7e3ec721.

FUOTA ENQUEUE does not wait for mc msg's but instantly goes to FRAG_STATUS

2 Answers