This message was deleted.

I’m sorry, but the knowledge sources do not describe any supported way to configure

destination-timeout-max-seconds

(or to populate

/flags

) specifically for Airbyte 2.x when deployed via

abctl

. What we do know: - The heartbeat / destination-timeout behavior is controlled via

flags.yaml

entries such as

destination-timeout-max-seconds

and

destination-timeout.failSync

, with the documentation stating a default of 24 hours. [[Heartbeats 2.0](https://docs.airbyte.com/platform/2.0/understanding-airbyte/heartbeats#technical-details)] - There is an open Helm v2 issue where

global.extraVolumes

/

global.extraVolumeMounts

are not wired into all deployments (server, connector-builder-server, temporal), which is how some users mount a

flags.yml

ConfigMap. [[Helm v2 extraVolumes](https://github.com/airbytehq/airbyte/issues/73268)] - In abctl-based installs, there are known gaps where Helm values and config files (including

/flags

) are not correctly propagated into runtime pods (e.g., resource limits being ignored,

/flags

path missing or empty). [[Resource limits ignored](https://github.com/airbytehq/airbyte/issues/73346); [Migration flags path](https://github.com/airbytehq/airbyte/issues/55251)] However, none of the provided sources document: - A working, documented mechanism in

abctl

to mount or populate

/flags

for replication pods in 2.0.x. - Any

values.yaml

key,

abctl

flag, or environment variable that overrides

destination-timeout-max-seconds

in an

abctl

deployment. Given that: - The docs assume a

flags.yaml

file is available but don’t cover how

abctl

wires it in. [[Heartbeats 2.0](https://docs.airbyte.com/platform/2.0/understanding-airbyte/heartbeats#technical-details)] - The Helm v2 chart currently has missing

extraVolumes

wiring for some components, and the issue is still open. [[Helm v2 extraVolumes](https://github.com/airbytehq/airbyte/issues/73268)] - There is an open, escalated issue about configuration not reaching runtime pods in

abctl

installs. [[Resource limits ignored](https://github.com/airbytehq/airbyte/issues/73346)] I cannot point to any reliable, documented configuration path for

destination-timeout-max-seconds

in an

abctl

deployment from these sources. Given these limitations, the most accurate guidance I can provide based on the sources is: - There is currently no documented, supported way (in the provided materials) to configure

destination-timeout-max-seconds

via

abctl

+ Helm v2. - This appears to be in the same class of issues as other abctl/Helm v2 configuration propagation bugs and may require an upstream fix to: - Properly mount a

flags.yaml

(e.g., via

global.extraVolumes

/

global.extraVolumeMounts

), and/or - Expose a chart value or env var that controls

destination-timeout-max-seconds

. I recommend: 1. Treat this as a product bug / gap and reference the existing Helm v2 and abctl issues when reporting it: - Missing

global.extraVolumes

wiring: [[Helm v2 extraVolumes](https://github.com/airbytehq/airbyte/issues/73268)] - Config not reaching runtime pods in abctl: [[Resource limits ignored](https://github.com/airbytehq/airbyte/issues/73346)] 2. Ask the Airbyte team (via GitHub or Slack) for: - A temporary workaround for mounting

flags.yaml

in abctl deployments, or - A patch to the Helm v2 chart / abctl that exposes

destination-timeout-max-seconds

. If you’d like, I can help you draft a concise GitHub issue tying your 2‑hour timeout observation to these existing configuration-propagation problems.

where do I actually add flags.yaml then?