You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Honor forwarder_stop_wait_for_inflight during shutdown. #2560
The core agent's forwarder_stop_wait_for_inflight setting selects how forwarder workers stop. Its default value, false, cancels in-flight HTTP requests; true waits for them to complete. The wait remains bounded by forwarder_stop_timeout.
ADP does not currently read this setting. Closing its forwarder handle stops new dispatch, waits for active request tasks to finish, and then flushes pending transactions to the retry queue. The topology-wide shutdown timeout bounds this drain.
ADP always behaves like forwarder_stop_wait_for_inflight: true. An operator cannot select the core agent's immediate-cancellation behavior by setting the key to false. This can make ADP wait for active requests until they finish or until the topology-wide shutdown timeout expires.
Proposal
Honor forwarder_stop_wait_for_inflight in the Datadog forwarder shutdown path:
Preserve the current bounded drain when the setting is true.
When it is false, cancel active HTTP requests without waiting for normal completion.
Preserve or requeue interrupted transactions where possible, and test both shutdown modes under active requests.
The implementation should continue to respect ADP's topology-wide shutdown timeout.
Alternatives and Discussion
ADP could retain its unconditional bounded-drain policy and document the difference. Supporting the setting instead gives operators the same shutdown-policy choice as the core agent.
It looks like this was added in DataDog/datadog-agent#52326 to support Serverless. One option we have, if this is difficult to support, is to gate the config option in the datadog-agent so that it only takes effect on Serverless (I only found 4 Agent hosts with it set to true, all in one org). We will need it eventually if Saluki becomes more used by Serverless, but we could wait until that point to implement it.
Activity
jszwedko commentedon Sep 8, 2026
It looks like this was added in DataDog/datadog-agent#52326 to support Serverless. One option we have, if this is difficult to support, is to gate the config option in the datadog-agent so that it only takes effect on Serverless (I only found 4 Agent hosts with it set to
true, all in one org). We will need it eventually if Saluki becomes more used by Serverless, but we could wait until that point to implement it.chore(config): update vendored datadog agent schema (#2562)
chore(config): update vendored datadog agent schema (#2562)