https://linen.dev logo
Join Slack
Powered by
<@U04S8PLJWMT>: Failed to save MongoDb due to the ...
# replication-ask-ai
e
@kapa.ai: Failed to save MongoDb due to the following error: errors.http.internalServerError
k
The knowledge sources only show that 
errors.http.internalServerError
corresponds to a generic HTTP 500 coming from the Airbyte backend (often wrapped as a 
HttpError
with 
status: 500
). They do not provide MongoDB‑specific root causes or fixes. [[platform 500 error](https://github.com/airbytehq/airbyte/issues/54058); [enterprise sources 500](https://github.com/airbytehq/airbyte/issues/53609)] From the examples, this error typically means: - The UI sent a request (e.g., to create or update a resource), - The server returned HTTP 500, and - The frontend surfaced it as 
errors.http.internalServerError
. [[helm auth 500](https://github.com/airbytehq/airbyte/issues/63274)] Because there is no MongoDB‑specific documentation in the provided sources, I can’t say exactly why saving your MongoDB source failed. To move forward, based only on what we know from similar 500s: 1. Check server logs (webapp / server / worker) around the time you tried to save the MongoDB source; the 500 root cause is usually only visible there. [[HTTP 500 stacktrace](https://github.com/airbytehq/airbyte/issues/72826)] 2. Try again after a short time in case it was a transient backend issue (some 5xx errors are intermittent). 3. Confirm your Airbyte version and, if you’re on an older dev/OSS build, consider upgrading, as several 500‑related issues were fixed in later versions in other contexts. [[enterprise sources 500](https://github.com/airbytehq/airbyte/issues/53609)] 4. If the error is reproducible, open an issue or support ticket with: - Exact Airbyte version - Full UI error payload (if available) - Relevant server logs (stack trace around the 500) - Steps to reproduce (what you entered in the MongoDB form) Without those logs or additional MongoDB‑specific docs, the knowledge sources do not contain enough information to pinpoint or resolve this particular 
errors.http.internalServerError
when saving MongoDB.
e
@kapa.ai: 2026-02-18 100629.329 Caused by: java.io.IOException: HTTP error: 500 Internal Server Error. 2026-02-18 100546.250 {"level":"info","ts":"2026-02-18T160546.250Z","msg":"history client encountered error","service":"matching","error":"Workflow task already started.","service-error-type":"serviceerror.TaskAlreadyStarted","logging-call-at":"/home/runner/work/docker-builds/docker-builds/temporal/client/history/metric_client.go:103"} - connector-sidecar
k
A message from kapa.ai
The knowledge sources only show that: - The 
java.io.IOException: HTTP error: 500 Internal Server Error
is a generic backend failure surfaced by the connector sidecar when it calls the Airbyte API. [[HTTP 500 stacktrace](https://github.com/airbytehq/airbyte/issues/72826)] - The Temporal log line 
history client encountered error ... "error":"Workflow task already started." ... "serviceerror.TaskAlreadyStarted"
is a known Temporal message that appears in Airbyte’s Temporal service logs and, by itself, is not treated as a fatal error for syncs. [[Temporal deadline issue](https://github.com/airbytehq/airbyte/issues/59730)] The provided sources do not explain a direct causal link between 
serviceerror.TaskAlreadyStarted
and the HTTP 500 from the connector‑sidecar, nor do they give a concrete fix for this combination of messages. So I can’t definitively say why your specific request failed. Based only on what’s in the sources, the actionable next step is: - Inspect the Airbyte server logs (API / worker) around 
2026-02-18 10:05–10:06
to find the full stack trace of the HTTP 500; that is where the real root cause is exposed. [[HTTP 500 stacktrace](https://github.com/airbytehq/airbyte/issues/72826)] If you can share that server-side stack trace (not just the connector‑sidecar and Temporal snippets), I can help interpret it within the limits of the available documentation.
e
What is the max http timeout - HTTP_IDLE_TIMEOUT ?
@kapa.ai: What is the max value of timeout for HTTP_IDLE_TIMEOUT and READ_TIMEOUT ?
k
A message from kapa.ai
The knowledge sources do not state any documented maximum allowed values for 
HTTP_IDLE_TIMEOUT
or 
READ_TIMEOUT
. They only show examples of values that users and docs have successfully used. From the docs and issues: - Official docs for scaling / schema discovery show:
Copy code
yaml   server:     extraEnv:       - name: HTTP_IDLE_TIMEOUT         value: 20m       - name: READ_TIMEOUT         value: 30m
[[Scaling Airbyte](https://docs.airbyte.com/platform/enterprise-setup/scaling-airbyte#schema-discovery-timeouts)] - Community examples use larger values, e.g.: - 
HTTP_IDLE_TIMEOUT: 1800s
(30 minutes) [[Java heapspace issue](https://github.com/airbytehq/airbyte/issues/51616)] - 
HTTP_IDLE_TIMEOUT: "10m"
and 
READ_TIMEOUT: "10m"
[[Deploy v1.6.0](https://github.com/airbytehq/airbyte/issues/58587)] - 
HTTP_IDLE_TIMEOUT: 3600s
/ 
60m
and 
READ_TIMEOUT: 3600s
/ 
60m
[[MSSQL 413 issue](https://github.com/airbytehq/airbyte/issues/56914)] None of these sources mention a hard upper bound (e.g., “cannot exceed X minutes/hours”), nor do they describe failures caused specifically by setting these timeouts “too high”. So, based on the available information: - We know values up to at least 60 minutes have been used. - We do not have documentation of a strict maximum limit for 
HTTP_IDLE_TIMEOUT
or 
READ_TIMEOUT
.
e
@kapa.ai -What is the ideal HTTP_TIMEOUT and READ_TIMEOUT for the mongoDB size of 300 GB and the airbyte cpu and memory size ?
k
A message from kapa.ai
The knowledge sources do not provide any guidance that ties 
HTTP_IDLE_TIMEOUT
or 
READ_TIMEOUT
to: - MongoDB database size (e.g., 300 GB), or - Airbyte CPU / memory sizing. They only describe these timeouts in the context of schema discovery taking a long time and show example values, without “ideal” recommendations per DB size. What we do have: - Official docs say that if schema discovery runs long (e.g., many tables/columns), you can increase timeouts like this: [[Scaling Airbyte](https://docs.airbyte.com/platform/enterprise-setup/scaling-airbyte#schema-discovery-timeouts)]
Copy code
yaml   server:     extraEnv:       - name: HTTP_IDLE_TIMEOUT         value: 20m       - name: READ_TIMEOUT         value: 30m
- For Helm chart v2, the same recommendation is expressed as: [[Scaling Airbyte](https://docs.airbyte.com/platform/enterprise-setup/scaling-airbyte#schema-discovery-timeouts)]
Copy code
yaml   server:     httpIdleTimeout: 20m     extraEnv:       - name: READ_TIMEOUT         value: 30m
- Community users have successfully used similar or larger values (20–60 minutes) when discovery was timing out, but again without any formula based on DB size or hardware. [[Scaling Airbyte 1.8](https://docs.airbyte.com/platform/1.8/enterprise-setup/scaling-airbyte#schema-discovery-timeouts); [MSSQL 413 issue](https://github.com/airbytehq/airbyte/issues/56914)] There is also MongoDB‑specific guidance for CDC initial load timeout, but that is a connector parameter (
Initial Load Timeout in Hours
/ 
Initial Load Timeout in Hours (Advanced)
), not the HTTP/READ timeouts on the server. For large or very large databases, it suggests 12–24 hours for the initial load, but this is independent of 
HTTP_IDLE_TIMEOUT
and 
READ_TIMEOUT
. [[CDC best practices](https://docs.airbyte.com/platform/understanding-airbyte/cdc-best-practices#source-configuration); [MongoDB v2 config](https://docs.airbyte.com/integrations/sources/mongodb-v2#configuration-parameters)] Because of this, I cannot state an “ideal” 
HTTP_IDLE_TIMEOUT
or 
READ_TIMEOUT
for a 300 GB MongoDB or for a specific CPU/memory profile—there is no such sizing rule in the provided documentation. What the docs effectively recommend is: - Start with the documented example for long schema discovery:
Copy code
yaml   server:     extraEnv:       - name: HTTP_IDLE_TIMEOUT         value: 20m       - name: READ_TIMEOUT         value: 30m
- If discovery or operations still time out, incrementally increase these values and observe behavior, but the knowledge sources do not define a safe or optimal upper bound.
e
@kapa.ai: 2026-02-18 193341,212 [main] ERROR i.a.a.c.c.ClientConfigurationSupport(generateDefaultRetryPolicy$lambda$3):63 - Failed to call unknown. Last response: null java.io.IOException: HTTP error: 500 Internal Server Error
k
A message from kapa.ai
The log line you’re seeing:
Copy code
text ERROR i.a.a.c.c.ClientConfigurationSupport ... - Failed to call unknown. Last response: null java.io.IOException: HTTP error: 500 Internal Server Error
matches the connector‑sidecar / client pattern from a known open issue where calls to the Airbyte Workload API fail with HTTP 500. [[HTTP 500 sidecar](https://github.com/airbytehq/airbyte/issues/72826)] From the available sources: - This is a generic backend failure: the client (connector‑sidecar) calls the Airbyte API, gets a 500, and retries until attempts are exhausted. [[HTTP 500 sidecar](https://github.com/airbytehq/airbyte/issues/72826)] - In Airbyte OSS v2.0.1 on Kubernetes/Helm, similar 500s have been linked to workload API authentication / token propagation issues between the main platform and connector‑sidecar. [[Sidecar auth issue](https://github.com/airbytehq/airbyte/issues/70451); [HTTP 500 sidecar](https://github.com/airbytehq/airbyte/issues/72826)] The knowledge sources do not provide a definitive root cause or fix for your exact timestamped error, but they suggest: 1. Check the Airbyte server / workload API logs around 
2026-02-18 19:33:41
to see the full stack trace of the 500; that’s where the real cause will appear. [[HTTP 500 sidecar](https://github.com/airbytehq/airbyte/issues/72826)] 2. If you’re on Kubernetes/Helm, review the workload API auth settings (e.g. 
API_AUTHORIZATION_ENABLED
, 
WORKLOAD_API_AUTH_HEADER
, 
WORKLOAD_API_BEARER_TOKEN
), as misconfiguration or missing tokens to the sidecar is a known problem in v2.0.1 OSS. [[HTTP 500 workaround](https://github.com/airbytehq/airbyte/issues/72826); [Sidecar auth issue](https://github.com/airbytehq/airbyte/issues/70451)] Beyond this, the knowledge sources do not contain enough information to say exactly why your call failed at that time. If you can extract and share the corresponding server‑side stack trace, it would allow more precise interpretation within these documented issues.
10 Views
Open in Slack
PreviousNext
Powered by