engine: added conditional to avoid re-scheduling conflict

When fluent-bit is shutting down it tries to immediately reschedule any
pending retries, however, due to how scheduling works a flush task can
be scheduled to run and (by signaling the appropriate pipe) then
flb_engine_reschedule_retries can try to invalidate it and re-schedule
it which in turn causes a problem when handle_output_event is invoked to
handle the result of the flush that was supposed to be aborted because
when a chunk has only one route it's always set down.

This is not the optimal approach but it's the safest one within the
limits of the system.

Signed-off-by: Leonardo Alminana <[email protected]>

Author: leonardo-albertovich

src/flb_engine.c

@@ -131,6 +131,15 @@ void flb_engine_reschedule_retries(struct flb_config *config)
         ins = mk_list_entry(head, struct flb_input_instance, _head);
         mk_list_foreach_safe(t_head, tmp_task, &ins->tasks) {
             task = mk_list_entry(t_head, struct flb_task, _head);
+
+            if (task->users > 0) {
+                flb_debug("[engine] retry=%p for task %i already scheduled to run, "
+                          "not re-scheduling it.",
+                          retry, task->id);
+
+                continue;
+            }
+
             mk_list_foreach_safe(rt_head, tmp_retry_task, &task->retries) {
                 retry = mk_list_entry(rt_head, struct flb_task_retry, _head);
                 flb_sched_request_invalidate(config, retry);