Can anyone assist me with the below issue kapa.ai couldnt answer this I am facing issue in select streams tab after define destination in airbyte ui i did open logs under did see some errors thw whole db size in almost 1tb and around 17000+ tables are there for all tables i have turned on cdc too this is the error in postgres-discover-12dfd5b8-2ff6-4fc3-b181-88f7c4235ae5-0-gdhrh pod 2026-02-24 120758,789 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresSource(supportResumableFullRefresh):939 stream io.airbyte.protocol.models.v0.ConfiguredAirbyteStream@10958e5[stream=io.airbyte.protocol.models.v0.AirbyteStream@dfa1f68[name=woi_workorderpeoplereportjoin,jsonSchema={"type":"object","properties":{"actual_start_date":{"type":"number","airbyte_type":"integer"},"middle_initial":{"type":"string"},"client_type":{"type":"number","airbyte_type":"integer"},"completed_date":{"type":"number","airbyte_type":"integer"},"corporate_e_mail":{"type":"string"},"company2":{"type":"string"},"company3":{"type":"string"},"manufacturer__2_":{"type":"string"},"categorization_tier_1":{"type":"string"},"categorization_tier_2":{"type":"string"},"categorization_tier_3":{"type":"string"},"geonet":{"type":"string"},"business_service":{"type":"string"},"priority":{"type":"number","airbyte_type":"integer"},"cost_center":{"type":"string"},"product_categorization_tier_2":{"type":"string"},"product_categorization_tier_1":{"type":"string"},"phone_number":{"type":"string"},"aschg":{"type":"string"},"region":{"type":"string"},"status":{"type":"number","airbyte_type":"integer"},"cost_center_code":{"type":"string"},"product_categorization_tier_3":{"type":"string"},"scheduled_end_date":{"type":"number","airbyte_type":"integer"},"vendor_group":{"type":"string"},"product_model_version__2_":{"type":"string"},"work_order_type":{"type":"number","airbyte_type":"integer"},"assignee_groups":{"type":"string"},"cab_manager___change_co_ord__":{"type":"string"},"assignee_groups_parent":{"type":"string"},"company":{"type":"string"},"status_reason":{"type":"number","airbyte_type":"integer"},"department":{"type":"string"},"first_name":{"type":"string"},"summary":{"type":"string"},"phone_number_pager":{"type":"string"},"jobtitle":{"type":"string"},"scheduled_start_date":{"type":"number","airbyte_type":"integer"},"vendor_ticket_number":{"type":"string"},"last_name":{"type":"string"},"mail_station":{"type":"string"},"internet_e_mail":{"type":"string"},"product_cat_tier_3__2_":{"type":"string"},"phone_number_business":{"type":"string"},"site_group":{"type":"string"},"detailed_description":{"type":"string"},"actual_end_date":{"type":"number","airbyte_type":"integer"},"record_id":{"type":"string"},"support_group_name":{"type":"string"},"site":{"type":"string"},"work_order_id":{"type":"string"},"product_cat_tier_1_2_":{"type":"string"},"organization":{"type":"string"},"product_cat_tier_2__2_":{"type":"string"},"request_id":{"type":"string"},"asgrp":{"type":"string"}}},supportedSyncModes=[full_refresh, incremental],sourceDefinedCursor=<null>,defaultCursorField=[],sourceDefinedPrimaryKey=[],namespace=public,isResumable=<null>,additionalProperties={}],syncMode=full_refresh,cursorField=[],destinationSyncMode=overwrite,primaryKey=[],generationId=<null>,minimumGenerationId=<null>,syncId=<null>,additionalProperties={}] will not sync in resumeable full refresh mode. 2026-02-24 120758,790 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresSource(supportResumableFullRefresh):939 stream io.airbyte.protocol.models.v0.ConfiguredAirbyteStream@3741c7de[stream=io.airbyte.protocol.models.v0.AirbyteStream@24a887a0[name=woi_workorderrelationshipinter,jsonSchema={"type":"object","properties":{"customer_phone_number":{"type":"string"},"middle_initial":{"type":"string"},"completed_date":{"type":"number","airbyte_type":"integer"},"request_type01":{"type":"number","airbyte_type":"integer"},"clientlocale":{"type":"string"},"company3":{"type":"string"},"categorization_tier_1":{"type":"string"},"associations_id":{"type":"string"},"categorization_tier_2":{"type":"string"},"categorization_tier_3":{"type":"string"},"customer_first_name":{"type":"string"},"location_company":{"type":"string"},"priority":{"type":"number","airbyte_type":"integer"},"srmsregistryinstanceid":{"type":"string"},"support_group_name2":{"type":"string"},"vendor_assignee_groups_parent":{"type":"string"},"status":{"type":"number","airbyte_type":"integer"},"ztmpeventguid":{"type":"string"},"wo_type_field_21":{"type":"string"},"scheduled_end_date":{"type":"number","airbyte_type":"integer"},"wo_type_field_22":{"type":"string"},"wo_type_field_20":{"type":"string"},"wo_type_field_25":{"type":"number","airbyte_type":"integer"},"wo_type_field_26":{"type":"number","airbyte_type":"integer"},"wo_type_field_23":{"type":"string"},"srmsaoiguid":{"type":"string"},"requestor_id":{"type":"string"},"association_type01":{"type":"number","airbyte_type":"integer"},"wo_type_field_24":{"type":"number","airbyte_type":"integer"},"wo_type_field_29":{"type":"string"},"customer_organization":{"type":"string"},"wo_type_field_27":{"type":"number","airbyte_type":"integer"},"wo_type_field_28":{"type":"string"},"product_name__2_":{"type":"string"},"customer_last_name":{"type":"string"},"support_organization2":{"type":"string"},"form_name02":{"type":"string"},"submit_date":{"type":"number","airbyte_type":"integer"},"status_reason":{"type":"number","airbyte_type":"integer"},"srattachment":{"type":"string"},"assigned_to":{"type":"string"},"wo_type_field_10":{"type":"string"},"wo_type_field_11":{"type":"string"},"wo_type_field_14":{"type":"string"},"wo_type_field_15":{"type":"string"},"wo_type_field_12":{"type":"string"},"wo_type_field_13":{"type":"string"},"srinstanceid":{"type":"string"},"wo_type_field_18":{"type":"string"},"last_name":{"type":"string"},"wo_type_field_19":{"type":"string"},"wo_type_field_16":{"type":"string"},"wo_type_field_17":{"type":"string"},"product_cat_tier_3__2_":{"type":"string"},"actual_end_date":{"type":"number","airbyte_type":"integer"},"site":{"type":"string"},"workorderid":{"type":"string"},"work_order_id":{"type":"string"},"product_cat_tier_1_2_":{"type":"string"},"organization":{"type":"string"},"ci_reconid":{"type":"string"},"actual_start_date":{"type":"number","airbyte_type":"integer"},"wo_type_field_5":{"type":"string"},"last_modified_date":{"type":"number","airbyte_type":"integer"},"wo_type_field_6":{"type":"number","airbyte_type":"integer"},"wo_type_field_3":{"type":"string"},"wo_type_field_4":{"type":"string"},"wo_type_field_9":{"type":"number","airbyte_type":"integer"},"wo_type_field_7":{"type":"number","airbyte_type":"integer"},"wo_type_field_8":{"type":"number","airbyte_type":"integer"},"srid":{"type":"string"},"customer_department":{"type":"string"},"customer_middle_name":{"type":"string"},"asgrpid":{"type":"string"},"wo_type_field_1":{"type":"string"},"wo_type_field_2":{"type":"string"},"person_id":{"type":"string"},"lookup_keyword":{"type":"string"},"add_request_for_":{"type":"number","airbyte_type":"integer"},"wo_type_field_30":{"type":"string"},"request_id01":{"type":"string"},"business_service":{"type":"string"},"templateid":{"type":"string"},"support_organization":{"type":"string"},"instanceid":{"type":"string"},"ascpy":{"type":"string"},"customer_internet_e_mail":{"type":"string"},"phone_number":{"type":"string"},"aschg":{"type":"string"},"requested_by_person_id":{"type":"string"},"submitter":{"type":"string"},"product_model_version__2_":{"type":"string"},"description":{"type":"string"},"work_order_type":{"type":"number","airbyte_type":"integer"},"assignee_groups":{"type":"string"},"ci_datasetid":{"type":"string"},"cab_manager___change_co_ord__":{"type":"string"},"assignee_groups_parent":{"type":"string"},"customer_person_id":{"type":"string"},"company":{"type":"string"},"customer_company":{"type":"string"},"first_name":{"type":"string"},"scheduled_start_date":{"type":"number","airbyte_type":"integer"},"detailed_description":{"type":"string"},"record_id":{"type":"string"},"aslogid":{"type":"string"},"support_group_name":{"type":"string"},"product_cat_tier_2__2_":{"type":"string"},"request_id":{"type":"string"},"vendor_assignee_groups":{"type":"string"},"asorg":{"type":"string"},"asgrp":{"type":"string"}}},supportedSyncModes=[full_refresh, incremental],sourceDefinedCursor=<null>,defaultCursorField=[],sourceDefinedPrimaryKey=[],namespace=public,isResumable=<null>,additionalProperties={}],syncMode=full_refresh,cursorField=[],destinationSyncMode=overwrite,primaryKey=[],generationId=<null>,minimumGenerationId=<null>,syncId=<null>,additionalProperties={}] will not sync in resumeable full refresh mode. 2026-02-24 120758,791 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresUtils(isCdc):70 using CDC: true 2026-02-24 120759,675 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.i.b.IntegrationRunner(runInternal):224 Completed integration: io.airbyte.cdk.integrations.base.ssh.SshWrappedSource 2026-02-24 120759,675 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresSource(main):752 completed source: class io.airbyte.integrations.source.postgres.PostgresSource 2026-02-24 120759,677 [main] INFO i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):281 - Checking for optional control message... 2026-02-24 120759,680 [main] INFO i.a.c.ConnectorMessageProcessor(setOutput):199 - Writing catalog result to API... 2026-02-24 120801,643 [main] ERROR i.a.c.ConnectorWatcher(handleException):200 - Error performing operation: io.airbyte.workers.exception.WorkerException io.airbyte.workers.exception.WorkerException: Unexpected error performing DISCOVER. The exit of the connector was: 0 at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:114) at io.airbyte.connectorSidecar.ConnectorWatcher.processConnectorOutput(ConnectorWatcher.kt:154) at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:79) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt) Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.setOutput(ConnectorMessageProcessor.kt:202) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:108) ... 4 common frames omitted 2026-02-24 120801,793 [main] INFO i.a.c.ConnectorWatcher(failWorkload):342 - Failing workload decd338e-5647-4c0b-adf4-da0e75f5a750_12dfd5b8-2ff6-4fc3-b181-88f7c4235ae5_0_discover. 2026-02-24 120801,873 [main] INFO i.a.c.ConnectorWatcher(exitInternalError):254 - Deliberately exiting process with code 1.

You’re running into a known platform limitation: the discover step is trying to send a very large catalog (because of ~17,000 tables + CDC metadata) back to the Airbyte API, and the HTTP request exceeds the server’s max payload size, resulting in: >

Client error : 413 Request Entity Too Large

This exact pattern (large schema / many tables → 413 / RESOURCE_EXHAUSTED) is documented as a UI/API limitation when loading very large catalogs. [UI table limit; MSSQL 413 issue] What’s happening in your logs: • The Postgres source completes discovery successfully (

Completed integration

,

completed source

). • The sidecar then tries to “write catalog result to API…”. • That call fails with

413 Request Entity Too Large

and the discover workload is marked as failed. [MSSQL 413 issue] Because the failure is at the API boundary, not in the connector, the root cause is the size of the discovered catalog (1 TB DB, 17k+ tables, CDC enabled on all). Practical workarounds Based on the available information, there is no documented server-side configuration in these sources to raise the limit, so the only reliable mitigations are to _reduce the size of each discover result_: 1. Split into multiple sources / connections ◦ Instead of one Postgres source covering the entire database, create several Postgres sources each limited to a subset of schemas or tables (e.g., by schema or functional domain). ◦ Each source will then produce a smaller catalog, staying under the payload limit. 2. Reduce the number of tables per source ◦ If possible, exclude non‑needed schemas/tables at the source definition level (e.g., only include specific schemas). ◦ This directly shrinks the discover catalog. 3. Limit CDC scope ◦ CDC adds extra metadata and configuration per stream; turning CDC on for every table in a 17k‑table DB is likely inflating the catalog. ◦ If feasible, enable CDC only for the tables you actually need in incremental/CDC mode; use full refresh for the rest. 4. Check for UI/catalog rendering limits ◦ There is prior guidance that loading more than ~6000 tables can cause resource exhaustion / large messages in the UI/API. [UI table limit] ◦ Keeping each source under that rough order of magnitude (or at least well below your current 17k) will help. About the “will not sync in resumable full refresh mode” lines Those log lines are informational: they just say certain streams won’t use Resumable Full Refresh (they’ll still sync, just without that feature). [Resumable FR] They are not the cause of the failure; the actual failure is the 413 when writing the catalog. ------------------------- Because the knowledge sources don’t document a configurable knob to increase the 413 limit, I can’t point you to a specific setting to change. If splitting the source/catalog is not acceptable in your environment, the next step would be to open a GitHub issue or support ticket referencing this 413 error and your catalog size, as this matches the known “too many tables / too large catalog” limitation. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

So give me the steps what should i do now @kapa.ai

Here’s what you can concretely do next, in order of least to most invasive changes. ------------------------- 1. Reduce the size of each discovery (split the catalog) Your error is exactly the same pattern as the MSSQL issue where discovery succeeds but fails when writing the catalog back with

413 Request Entity Too Large

. [MSSQL 413] Because the problem is the size of the discovered catalog, the only documented, reliable mitigation in the sources is to reduce how much is discovered per source: 1. Create multiple Postgres sources, each limited to a subset of the DB: ◦ For example: ▪︎ Source A: only schemas

schema1, schema2, schema3

▪︎ Source B: only schemas

schema4, schema5

, etc. ◦ Keep each source to a much smaller number of tables (ideally well below the 17k you have now; note that even ~6000 tables has been reported as problematic for the UI/API). [UI table limit] 2. For each new source: ◦ Go through the normal “Set up source” flow. ◦ In the configuration, restrict which schemas/tables are included (if your version/connector allows schema filtering at setup). ◦ Run Discover again for that smaller subset. 3. Then: ◦ Create separate connections from each source to your destination. ◦ Select only the streams you need in each connection. This directly shrinks the JSON catalog that the sidecar sends to the API, avoiding the 413. ------------------------- 2. Limit CDC to only the tables that really need it CDC metadata also contributes to catalog size. With CDC turned on for all 17k+ tables, the catalog is very large. Within each smaller source you create: 1. Enable CDC only for the tables that truly need log‑based incremental sync. 2. For less critical or rarely changing tables, use: ◦

Full refresh | overwrite

or ◦

Full refresh | append

(depending on your use case). This reduces catalog complexity and may help keep each discover result under the size limit. ------------------------- 3. If you’re on a Helm/Kubernetes install, verify (but don’t rely on) timeout/size settings The docs show how to increase timeouts for long‑running discovery, but they do not document a way to raise the HTTP body size limit that is causing your 413. [Scaling Airbyte] If you’re already using Helm: • You can ensure your

values.yaml

has something like:

server:
      httpIdleTimeout: 20m
      extraEnv:
        - name: READ_TIMEOUT
          value: 30m

(or

extraEnvs

depending on chart version). [Scaling Airbyte] This helps if discovery is timing out, but it will not fix the 413 by itself according to the available docs. ------------------------- 4. If splitting still fails, involve support / open an issue The knowledge sources don’t document a server‑side configuration to increase the 413 limit, so if: • You’ve split the DB into multiple smaller sources, and • Each source still fails discovery with

413 Request Entity Too Large

, then the next step is to: 1. Collect: ◦ Airbyte version ◦ Postgres source version ◦ Approx. number of tables per source ◦ The exact 413 stack trace (like you pasted) 2. Open a GitHub issue or support ticket referencing the known 413 catalog‑size problem. [MSSQL 413] ------------------------- Summary of actions for you now 1. Do not try to discover the entire 1 TB / 17k‑table DB in a single source. 2. Create multiple Postgres sources, each limited to a subset of schemas/tables. 3. Enable CDC only where needed within each smaller source. 4. Re‑run discovery on each smaller source and then configure connections. 5. If a single smaller source still triggers 413, escalate with logs, as there’s no documented knob to raise that limit in the provided materials. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai i have created with 1000 tables per publication and still there is issue .airbyte.workers.exception.WorkerException: Unexpected error performing DISCOVER. The exit of the connector was: 0 at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:114) at io.airbyte.connectorSidecar.ConnectorWatcher.processConnectorOutput(ConnectorWatcher.kt:154) at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:79) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt) Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.setOutput(ConnectorMessageProcessor.kt:202) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:108)

Even with 1,000 tables per source, you're still hitting the 413. This confirms the issue is the HTTP body size limit on the Airbyte server side, not just the number of tables. The catalog payload for 1,000 tables (especially with CDC metadata and wide schemas like yours) is still too large. Based on the knowledge sources, here is what has been attempted by others in the same situation and what the docs say: ------------------------- What others have tried (from the MSSQL 413 issue) The following

values.yaml

configuration was attempted but did not fully resolve the issue for everyone: [MSSQL 413]

global:
  env_vars:
    HTTP_IDLE_TIMEOUT: 3600s
    MICRONAUT_SERVER_MAX_REQUEST_SIZE: "104857600" # 100MB

webapp:
  ingress:
    annotations:
      nginx.ingress.kubernetes.io/proxy-send-timeout: 3600
      nginx.ingress.kubernetes.io/proxy-read-timeout: 3600
      nginx.ingress.kubernetes.io/proxy-body-size: "50m"

server:
  extraEnvs:
    - name: HTTP_IDLE_TIMEOUT
      value: 60m
    - name: READ_TIMEOUT
      value: 60m

You can try applying this if you haven't already, but the knowledge sources do not confirm this definitively resolves the 413 for large catalogs. ------------------------- What the official docs recommend For schema discovery timeouts/size issues, the documented approach is: [Scaling Airbyte]

server:
  httpIdleTimeout: 20m
  extraEnv:
    - name: READ_TIMEOUT
      value: 30m

------------------------- What I cannot confirm from the knowledge sources The knowledge sources do not document a definitive configuration knob that resolves the 413 body size limit when the catalog itself is too large. The 413 is happening at

writeDiscoverCatalogResult

— meaning the connector finishes successfully, but the result payload is rejected by the API server as too large. [MSSQL 413] ------------------------- Recommended next steps 1. Try reducing further — even 1,000 tables with wide schemas (like the ones in your logs with 50+ columns each) and CDC metadata can produce a very large payload. Try 200–300 tables per source to see where the threshold is. 2. Open a GitHub issue or contact Airbyte support — this is a known but unresolved limitation. Provide: ◦ Your Airbyte version ◦ Postgres source version ◦ Number of tables per source ◦ The 413 stack trace ◦ Your current

values.yaml

configuration 3. Reference the existing MSSQL 413 issue as a related case: [MSSQL 413] The knowledge sources do not contain a confirmed fix for this specific scenario beyond what's been shared above. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

Aswin [4:22 PM] @kapa.ai this is postgres not mysql i have created with 1000 tables per publication and still there is issue .airbyte.workers.exception.WorkerException: Unexpected error performing DISCOVER. The exit of the connector was: 0 at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:114) at io.airbyte.connectorSidecar.ConnectorWatcher.processConnectorOutput(ConnectorWatcher.kt:154) at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:79) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt) Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.setOutput(ConnectorMessageProcessor.kt:202) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:108)

You're correct — this is a Postgres source, and the same 413 error applies regardless of the connector type. The root cause is identical: the catalog payload from discovering 1,000 tables is still too large for the Airbyte API to accept. [MSSQL 413] There is also a known related issue specifically for the Postgres source connector where the discover operation executes heavy metadata queries without respecting schema filters, which can make the problem worse in large databases. [Postgres discover issue] What you can try right now 1. Apply these Helm

values.yaml

settings (if you haven't already):

global:
  env_vars:
    HTTP_IDLE_TIMEOUT: 3600s
    MICRONAUT_SERVER_MAX_REQUEST_SIZE: "104857600" # 100MB

webapp:
  ingress:
    annotations:
      nginx.ingress.kubernetes.io/proxy-send-timeout: 3600
      nginx.ingress.kubernetes.io/proxy-read-timeout: 3600
      nginx.ingress.kubernetes.io/proxy-body-size: "50m"

server:
  httpIdleTimeout: 20m
  extraEnv:
    - name: READ_TIMEOUT
      value: 30m

[MSSQL 413; Scaling Airbyte] 2. Reduce tables further — your tables have very wide schemas (50+ columns each). Even 1,000 wide tables with CDC metadata can exceed the limit. Try 200–300 tables per source to find a working threshold. 3. Escalate to Airbyte — the knowledge sources do not document a confirmed fix for this at 1,000 tables. You should: • Open a GitHub issue referencing both the Postgres discover issue (schema filter not respected) and the 413 issue • Include your Airbyte version, Postgres source version, number of tables, and the 413 stack trace The knowledge sources do not contain a confirmed resolution beyond what's listed above. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

on: io.airbyte.cdk.integrations.base.ssh.SshWrappedSource 2026-03-02 110515,525 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresSource(main):752 completed source: class io.airbyte.integrations.source.postgres.PostgresSource 2026-03-02 110515,527 [main] INFO i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):281 - Checking for optional control message... 2026-03-02 110515,530 [main] INFO i.a.c.ConnectorMessageProcessor(setOutput):199 - Writing catalog result to API... 2026-03-02 110518,120 [main] ERROR i.a.c.ConnectorWatcher(handleException):200 - Error performing operation: io.airbyte.workers.exception.WorkerException io.airbyte.workers.exception.WorkerException: Unexpected error performing DISCOVER. The exit of the connector was: 0 at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:114) at io.airbyte.connectorSidecar.ConnectorWatcher.processConnectorOutput(ConnectorWatcher.kt:154) at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:79) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt) Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.setOutput(ConnectorMessageProcessor.kt:202) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor. @kapa.ai same again should we still raise the metrics as you say? this is my whole values.yaml file global: airbyteUrl: https://airbyte.dbaas.testrun env_vars: HTTP_IDLE_TIMEOUT: 3600s MICRONAUT_SERVER_MAX_REQUEST_SIZE: "104857600" # 100MB webapp: ingress: annotations: nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-body-size: "50m" server: httpIdleTimeout: 20m extraEnv: - name: READ_TIMEOUT value: 30m

Your

values.yaml

is missing the

MICRONAUT_SERVER_MAX_REQUEST_SIZE

setting on the server level, and more importantly, the 413 is happening at the Airbyte API server (

writeDiscoverCatalogResult

), not at the nginx ingress. So increasing the nginx body size alone isn't enough — the Micronaut server itself is rejecting the payload. Looking at your current config vs. what was attempted in the known 413 issue [MSSQL 413], here's what's missing: Updated

values.yaml

to try

global:
  airbyteUrl: https://airbyte.dbaas.testrun
  env_vars:
    HTTP_IDLE_TIMEOUT: 3600s
    MICRONAUT_SERVER_MAX_REQUEST_SIZE: "104857600" # 100MB

webapp:
  ingress:
    annotations:
      nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-body-size: "50m"

server:
  httpIdleTimeout: 20m
  extraEnv:
    - name: READ_TIMEOUT
      value: 30m
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "104857600"  # 100MB — add this directly on the server pod

The key addition is

MICRONAUT_SERVER_MAX_REQUEST_SIZE

as an

extraEnv

on the server pod, not just as a global env var. The global

env_vars

block may not propagate to the server pod depending on your Helm chart version. [MSSQL 413] ------------------------- Should you raise a GitHub issue? Yes, you should. The knowledge sources confirm this is a known but unresolved limitation — the existing MSSQL 413 issue was closed without a confirmed fix for large catalogs, and there is a separate open Postgres issue about discover not respecting schema filters. [MSSQL 413; Postgres discover issue] When raising the issue, include: • Your Airbyte version • Postgres source connector version • Number of tables per source (you've tried 1,000) • Your full

values.yaml

• The 413 stack trace • Reference to both issues above ------------------------- In parallel: keep reducing table count The knowledge sources do not confirm that any configuration change definitively resolves the 413 for large catalogs. Until a fix is confirmed, try reducing to 200–300 tables per source to find a working threshold while the issue is being investigated. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai i have applied by using helm upgrade airbyte airbyte/airbyte --namespace airbyte -f values.yaml Is this fine or edit some where else?

Your Helm upgrade command looks correct in structure, but there's one important detail to check: which Helm chart repository you're using. The command you ran:

helm upgrade airbyte airbyte/airbyte --namespace airbyte -f values.yaml

This uses the Helm chart V1 repository (

airbyte/airbyte

). If you're on Helm chart V2, the correct command is different: [Upgrading Airbyte]

# Helm chart V1
helm upgrade --install <RELEASE-NAME> airbyte/airbyte --values values.yaml --version <HELM-APP-VERSION>

# Helm chart V2
helm upgrade airbyte airbyte-v2/airbyte \
  --namespace airbyte-v2 \
  --values ./values.yaml \
  --version 2.x.x

To verify which version you're on Run:

helm list -n airbyte

This will show your current chart version. [Upgrading Airbyte] ------------------------- After applying the upgrade To confirm the new env vars are actually applied to the server pod, run:

kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

If

MICRONAUT_SERVER_MAX_REQUEST_SIZE

doesn't appear in the server pod's environment, the global

env_vars

block is not propagating to it, and you need the

server.extraEnv

addition from the previous recommendation. ------------------------- Summary • The command structure is fine for V1. • Make sure you're targeting the right chart repo (V1 vs V2). • After upgrade, verify the env var is present on the server pod before retrying discovery — that's the critical check to confirm the fix is actually applied. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai [aamala@dbaasjump004 ~]$ kubectl get pods -n airbyte NAME READY STATUS RESTARTS AGE airbyte-airbyte-bootloader 0/1 Completed 0 83s airbyte-connector-builder-server-5566b578df-gdfbp 1/1 Running 0 14m airbyte-cron-685f49b85f-hwmj8 1/1 Running 0 14m airbyte-db-0 1/1 Running 0 93d airbyte-minio-0 1/1 Running 0 93d airbyte-server-d7dbf6695-lvbqt 1/1 Running 0 14m airbyte-temporal-5848f7f76d-9r5xx 1/1 Running 0 14m airbyte-worker-5cf85998d-x6wzd 1/1 Running 0 14m airbyte-workload-api-server-65c5dc68d8-8v4qk 1/1 Running 0 14m airbyte-workload-launcher-7ccc596bc4-qmsqk 1/1 Running 2 (13m ago) 14m postgres-discover-09d3f9da-4637-4056-a3a8-7cc34f648de0-0-idgiu 0/2 Error 0 12m postgres-discover-51a69a77-2320-4c61-9a96-91c6e99b0ddc-0-pakxz 0/2 Error 0 97m postgres-discover-7ee79335-0010-461f-a5f4-7c30a66603c9-0-cfxpn 0/2 Error 0 42m postgres-discover-92066890-6717-444a-bb12-3881585e99bb-0-hanol 0/2 Error 0 87m postgres-discover-9595a787-145a-4556-a313-c6ddfe4277e9-0-pzfmq 0/2 Error 0 102m postgres-discover-b0f58ca7-564d-46b7-b512-9f5169ca94d3-0-cwuae 0/2 Error 0 82m postgres-discover-b4373a93-f3d7-48e3-98bc-55d7d8500be6-0-jwtgc 0/2 Error 0 92m postgres-discover-dd2d6536-0bf3-4f25-a268-b6cdefaaaf04-0-yqntd 0/2 Error 0 107m [aamala@dbaasjump004 ~]$ kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE" WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/aamala/.kube/dev_he Release "airbyte" has been upgraded. Happy Helming! NAME: airbyte LAST DEPLOYED: Mon Mar 2 131115 2026 NAMESPACE: airbyte STATUS: deployed REVISION: 4 NOTES: Get the application URL by running these commands: echo "Visit http://127.0.0.1:8080 to use your application" kubectl -n airbyte port-forward deployment/airbyte-server 8080:8001 [aamala@dbaasjump004 ~]$ helm list -n airbyte WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/aamala/.kube/dev_he WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/aamala/.kube/dev_he NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION airbyte airbyte 4 2026-03-02 131115.653421514 +0200 EET deployed airbyte-1.9.2 2.0.1 [aamala@dbaasjump004 ~]$ kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE" No resources found in airbyte namespace.

The fact that

kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

returned no output confirms that the environment variable is not being applied to the server pod. This means your

values.yaml

change (putting

MICRONAUT_SERVER_MAX_REQUEST_SIZE

under

global.env_vars

) is not propagating to the server container. Fix: Add it directly to the server pod via

extraEnv

Update your

values.yaml

to explicitly set it on the server pod:

global:
  airbyteUrl: https://airbyte.dbaas.testrun
  env_vars:
    HTTP_IDLE_TIMEOUT: 3600s
    MICRONAUT_SERVER_MAX_REQUEST_SIZE: "104857600"  # 100MB

webapp:
  ingress:
    annotations:
      nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-body-size: "50m"

server:
  httpIdleTimeout: 20m
  extraEnv:
    - name: READ_TIMEOUT
      value: 30m
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "104857600"  # 100MB — explicitly on the server pod

Then re-apply:

helm upgrade airbyte airbyte/airbyte --namespace airbyte -f values.yaml

After upgrade, verify it's applied

kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

You should now see the variable listed in the server pod's environment. If it appears, then retry your Postgres source discovery. Also note: your multiple

postgres-discover-*

pods are all in

Error

state, which is consistent with the ongoing 413 failures. [MSSQL 413] Those will keep accumulating until the underlying issue is resolved — you can clean them up with:

kubectl delete pods -n airbyte -l app=airbyte-discover

or manually delete the errored pods once you're ready to retry. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai [aamala@dbaasjump004 ~]$ kubectl get pods -n airbyte NAME READY STATUS RESTARTS AGE airbyte-airbyte-bootloader 0/1 Completed 0 83s airbyte-connector-builder-server-5566b578df-gdfbp 1/1 Running 0 14m airbyte-cron-685f49b85f-hwmj8 1/1 Running 0 14m airbyte-db-0 1/1 Running 0 93d airbyte-minio-0 1/1 Running 0 93d airbyte-server-d7dbf6695-lvbqt 1/1 Running 0 14m airbyte-temporal-5848f7f76d-9r5xx 1/1 Running 0 14m airbyte-worker-5cf85998d-x6wzd 1/1 Running 0 14m airbyte-workload-api-server-65c5dc68d8-8v4qk 1/1 Running 0 14m airbyte-workload-launcher-7ccc596bc4-qmsqk 1/1 Running 2 (13m ago) 14m postgres-discover-09d3f9da-4637-4056-a3a8-7cc34f648de0-0-idgiu 0/2 Error 0 12m postgres-discover-51a69a77-2320-4c61-9a96-91c6e99b0ddc-0-pakxz 0/2 Error 0 97m postgres-discover-7ee79335-0010-461f-a5f4-7c30a66603c9-0-cfxpn 0/2 Error 0 42m postgres-discover-92066890-6717-444a-bb12-3881585e99bb-0-hanol 0/2 Error 0 87m postgres-discover-9595a787-145a-4556-a313-c6ddfe4277e9-0-pzfmq 0/2 Error 0 102m postgres-discover-b0f58ca7-564d-46b7-b512-9f5169ca94d3-0-cwuae 0/2 Error 0 82m postgres-discover-b4373a93-f3d7-48e3-98bc-55d7d8500be6-0-jwtgc 0/2 Error 0 92m postgres-discover-dd2d6536-0bf3-4f25-a268-b6cdefaaaf04-0-yqntd 0/2 Error 0 107m [aamala@dbaasjump004 ~]$ kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE" WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/aamala/.kube/dev_he Release "airbyte" has been upgraded. Happy Helming! NAME: airbyte LAST DEPLOYED: Mon Mar 2 131115 2026 NAMESPACE: airbyte STATUS: deployed REVISION: 4 NOTES: Get the application URL by running these commands: echo "Visit http://127.0.0.1:8080 to use your application" kubectl -n airbyte port-forward deployment/airbyte-server 8080:8001 [aamala@dbaasjump004 ~]$ helm list -n airbyte WARNING: Kubernetes configuration file is group-readable. This is insecure. Location: /home/aamala/.kube/dev_he WARNING: Kubernetes configuration file is world-readable. This is insecure. Location: /home/aamala/.kube/dev_he NAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION airbyte airbyte 4 2026-03-02 131115.653421514 +0200 EET deployed airbyte-1.9.2 2.0.1 [aamala@dbaasjump004 ~]$ kubectl describe pod -n airbyte -l app=airbyte-server | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE" No resources found in airbyte namespace. (edited)

The pod is still showing the same name (

airbyte-server-d7dbf6695-lvbqt

) and AGE is

14m

— which means the server pod did not restart after your last

helm upgrade

. This is why the env var isn't showing up: the old pod is still running with the old configuration. Step 1: Check if the server pod restarted

kubectl get pods -n airbyte | grep airbyte-server

If the pod name and AGE haven't changed since your upgrade, the deployment wasn't updated (possibly because Helm didn't detect a change that would trigger a rollout). Step 2: Force a rollout restart of the server

kubectl rollout restart deployment/airbyte-server -n airbyte

Then wait for the new pod to come up:

kubectl get pods -n airbyte -w

Step 3: Get the new pod name and verify the env var Once the new pod is running:

kubectl get pods -n airbyte | grep airbyte-server

Then use the new pod name to check:

kubectl describe pod -n airbyte <new-server-pod-name> | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

Step 4: Also confirm your

values.yaml

uses

extraEnvs

(plural) You are on Helm chart V1 (

airbyte-1.9.2

). The correct key in V1 is

extraEnvs

(with an s): [Upgrading Airbyte]

server:
  httpIdleTimeout: 20m
  extraEnvs:
    - name: READ_TIMEOUT
      value: 30m
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "104857600"

If you had

extraEnv

(without the s), Helm chart V1 would silently ignore it, which would explain why the env var never appeared on the pod. Fix the key, re-run

helm upgrade

, then force the rollout restart. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: BUILD — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: CLAIM — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info Claimed: true for workload decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover via API in dataplane aaf342ea-4efe-4c6e-b833-0f452ffe36d3 (21e65012-89f0-435f-be36-ab07ce3fdc5d) 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: LOAD_SHED — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: CHECK_STATUS — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info No pod found running for workload decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: MUTEX — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info No mutex key specified for workload: decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover. Continuing... 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: ARCHITECTURE — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info APPLY Stage: LAUNCH — (workloadId=decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover) 2026-03-02 164937 INFO 2026-03-02 164937 info [initContainer] image: airbyte/workload-init-container:2.0.1 resources: ResourceRequirements(claims=[], limits={}, requests={}, additionalProperties={}) 2026-03-02 164948 INFO 2026-03-02 164948 info Attempting to update workload: decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover to LAUNCHED. 2026-03-02 164948 INFO 2026-03-02 164948 info Pipeline completed for workload: decd338e-5647-4c0b-adf4-da0e75f5a750_05b40c2e-7e4f-4fa3-898f-ceaae48e74ae_0_discover. 2026-03-02 164952 INFO 2026-03-02 164952 info 2026-03-02 164952 INFO 2026-03-02 164952 info Transitioning workload to running state 2026-03-02 164952 INFO 2026-03-02 164952 info ----- START DISCOVER ----- 2026-03-02 164952 INFO 2026-03-02 164952 info 2026-03-02 164952 INFO 2026-03-02 164952 info Workload successfully transitioned to running state still on issue

The logs you're sharing now show the discover workload is launching successfully (BUILD → CLAIM → LAUNCH → RUNNING → START DISCOVER). This is actually progress — the pod is starting. The question is whether it still fails with 413 at the end when writing the catalog result. What to check next 1. Confirm the env var is now on the server pod First, get the current server pod name:

kubectl get pods -n airbyte | grep airbyte-server

Then check if

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is present:

kubectl describe pod -n airbyte <current-server-pod-name> | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

2. Wait for the discover pod to finish and check its logs The logs you pasted show the discover is still in progress (

----- START DISCOVER -----

). Wait for it to complete, then check the result:

kubectl logs -n airbyte <postgres-discover-pod-name> -c connector-sidecar

Look for either: •

Writing catalog result to API...

followed by success → the fix worked •

Client error : 413 Request Entity Too Large

→ the env var is still not applied to the server 3. If still 413 — confirm your

values.yaml

uses

extraEnvs

(plural) You are on Helm chart V1 (

airbyte-1.9.2

). The correct syntax is

extraEnvs

with an s: [MSSQL 413]

server:
  httpIdleTimeout: 20m
  extraEnvs:
    - name: READ_TIMEOUT
      value: 30m
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "104857600"

And force a restart if the pod hasn't cycled since your last upgrade:

kubectl rollout restart deployment/airbyte-server -n airbyte

The key thing to confirm is whether

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is actually visible in the server pod's environment — that's the definitive check before concluding whether the fix is applied or not. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

yes as upi are asking everything are right

New message text here

@kapa.ai how to over come this problem now?

Based on our conversation so far, here's a consolidated summary of everything you can do to overcome the 413 error: ------------------------- Current Status & What's Been Done You've already: • Applied

MICRONAUT_SERVER_MAX_REQUEST_SIZE

to the server pod ✅ • Applied nginx ingress size/timeout settings ✅ • Applied

httpIdleTimeout

and

READ_TIMEOUT

✅ • Split to ~1,000 tables per source ✅ ------------------------- Remaining Options 1. Check if the latest discover actually succeeded First, confirm whether the fix worked for the current running discover:

kubectl get pods -n airbyte | grep postgres-discover
kubectl logs -n airbyte <latest-discover-pod-name> -c connector-sidecar | tail -50

Look for success or another 413. 2. If still failing — reduce tables further 1,000 tables with 50+ columns each still produces a very large catalog payload. Try 200–300 tables per source to find a working threshold. [MSSQL 413] 3. Limit CDC scope CDC metadata inflates the catalog significantly. Enable CDC *only on tables that truly need it*; use full refresh for the rest. This directly reduces catalog payload size. 4. Open a GitHub issue with Airbyte The knowledge sources do not document a confirmed fix beyond what you've already applied. [MSSQL 413] You should escalate with: • Airbyte version:

2.0.1

• Helm chart:

airbyte-1.9.2

• Postgres source version • Number of tables per source (tried 1,000) • Your

values.yaml

• The 413 stack trace • Reference to the existing 413 issue ------------------------- The most actionable immediate step is to check the current discover pod logs to confirm whether the env var fix resolved it, and if not, reduce to 200–300 tables per source while raising a GitHub issue in parallel. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

hi @kapa.ai, I have reduced the batch size to 200 tables per source and increased

MICRONAUT_SERVER_MAX_REQUEST_SIZE

to 500 MB, but I am still facing the same issue. How can I overcome this? Also, since each source connection has its own publication name and we run the

ALTER PUBLICATION

command for those 200 tables, how will enabling the CDC option for 80% of the tables affect this? Only the data of those 200 tables included in the publication would be considered for source discovery and data input, right? Will providing any log dumps help you identify the core problem so that I can proceed further? If so, please let me know the steps to collect and share them

You've done everything the documented sources recommend, and you're still hitting the 413. Let me address each of your questions: ------------------------- 1. Still getting 413 with 200 tables and 500MB limit The knowledge sources do not contain a confirmed fix for this scenario beyond what you've already applied. [MSSQL 413] At this point, the issue is likely that even 200 wide tables (50+ columns each, with CDC metadata) still produces a payload the server rejects. Verify the 500MB setting is actually on the server pod:

kubectl get pods -n airbyte | grep airbyte-server
kubectl describe pod -n airbyte <server-pod-name> | grep -A2 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

Confirm the value shows

524288000

(500MB in bytes) or

"524288000"

. ------------------------- 2. CDC with publications and 200 tables Yes, your understanding is correct. When you create a Postgres source with a specific publication name and run:

ALTER PUBLICATION <publicationName> ADD TABLE <table1>, <table2>, ...;

Only the tables included in that publication are tracked for CDC changes. [Postgres troubleshooting] However, there are important CDC requirements to be aware of: • CDC only works for tables with primary keys. Tables without primary keys must use Full Refresh sync. [Postgres troubleshooting] • Each Airbyte CDC source should only connect to one destination — multiple destinations would each receive only part of the data. [Postgres troubleshooting] • Schema changes are not supported automatically for CDC — you'd need to reset and resync if schema changes occur. [Postgres troubleshooting] So enabling CDC for 80% of the 200 tables is fine as long as those tables have primary keys. The publication controls what's tracked at the Postgres level. ------------------------- 3. Log collection to identify the core problem Yes, sharing logs would help narrow down whether the issue is: • The catalog payload still being too large (413 at

writeDiscoverCatalogResult

) • A different error entirely Steps to collect relevant logs: a) Get the latest discover pod name:

kubectl get pods -n airbyte | grep postgres-discover

b) Get logs from the connector sidecar container:

kubectl logs -n airbyte <postgres-discover-pod-name> discover-sidecar.log

c) Get logs from the connector container:

kubectl logs -n airbyte <postgres-discover-pod-name> discover-connector.log

d) Get server logs around the time of the failure:

kubectl logs -n airbyte <airbyte-server-pod-name> server.log

e) Confirm the env var on the server pod:

kubectl describe pod -n airbyte <airbyte-server-pod-name> server-describe.txt

Share the tail of

discover-sidecar.log

(last 100 lines) — specifically the section around

Writing catalog result to API...

— as that will confirm whether the 413 is still the root cause or if something else has changed. ------------------------- 4. Recommended next step regardless Since you've exhausted the documented configuration options, open a GitHub issue on the Airbyte repository referencing the existing 413 issue and the Postgres discover issue. Include your Airbyte version (

2.0.1

), table count (200), column counts,

MICRONAUT_SERVER_MAX_REQUEST_SIZE

value, and the stack trace. The knowledge sources do not document a confirmed resolution for this at your scale. [MSSQL 413; Postgres discover issue] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, do you think its an issue? 2026-03-04 121344,313 [main] INFO i.m.c.e.DefaultEnvironment(<init>):170 - Established active environments: [worker-v2, control-plane, oss, local-secrets] 2026-03-04 121345,045 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.netty' 2026-03-04 121345,046 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari' 2026-03-04 121345,046 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.grpc' 2026-03-04 121345,046 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.temporal' 2026-03-04 121345,046 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'ERROR' for logger: 'com.zaxxer.hikari.pool' 2026-03-04 121345,047 [main] INFO i.m.l.PropertiesLoggingLevelsConfigurer(configureLogLevelForPrefix):113 - Setting log level 'INFO' for logger: 'io.fabric8.kubernetes.client' 2026-03-04 121345,072 [main] INFO i.m.r.Micronaut(start):183 - No embedded container found. Running as CLI application 2026-03-04 121347,112 [pool-3-thread-1] INFO i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 - 2026-03-04 121347,112 [pool-2-thread-1] INFO i.a.c.HeartbeatMonitor$HeartbeatTask(run):92 - Transitioning workload to running state 2026-03-04 121347,113 [main] INFO i.a.c.ConnectorWatcher(processConnectorOutput):138 - Connector exited, processing output 2026-03-04 121347,146 [pool-3-thread-1] INFO i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 - ----- START CHECK ----- 2026-03-04 121347,147 [pool-3-thread-1] INFO i.a.c.i.LineGobbler$Companion(gobble$lambda$2):108 -

These logs are from a CHECK operation (connection test), not a DISCOVER. The key line is:

----- START CHECK -----

This is normal startup/initialization output for the connector sidecar. The logs you've shared here show: • Micronaut environment initialized (

worker-v2, control-plane, oss, local-secrets

) ✅ • Log levels configured ✅ • Workload transitioned to running state ✅ • Connector exited and output is being processed ✅ • CHECK operation started ✅ These logs by themselves do not show an error. They are cut off before the CHECK completes, so we can't tell from this snippet whether it succeeded or failed. What to do Get the full logs from this pod to see the outcome:

kubectl logs -n airbyte <pod-name> -c connector-sidecar

Look for either: • ✅ A success message indicating the connection check passed • ❌ A

413 Request Entity Too Large

or other error at the end These initialization logs are not the cause of your issue — the 413 error in your case always appears at the very end, at the

writeDiscoverCatalogResult

step, not during startup. [MSSQL 413] Can you share the tail end of the full logs (last 50–100 lines) from the discover pod? That's where the actual error or success will appear. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai i have tried with 10 tables even with that it fails why?

This is a significant finding. If even 10 tables fails with 413, the problem is not the number of tables — it means

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is still not actually being applied to the server pod, regardless of what's in your

values.yaml

. Step 1: Definitively confirm the env var on the server pod

kubectl get pods -n airbyte | grep airbyte-server
kubectl exec -n airbyte <server-pod-name> -- env | grep MICRONAUT

This directly reads the environment inside the running container. If

MICRONAUT_SERVER_MAX_REQUEST_SIZE

does not appear here, the setting is not applied — full stop. Step 2: Check the actual error in the discover pod logs With only 10 tables, the payload cannot be large enough to cause a genuine 413 size limit. This means either: • The size limit is still at its default (very small), OR • The error is something different now (not actually a size issue) Get the full logs from the latest discover pod:

kubectl get pods -n airbyte | grep postgres-discover
kubectl logs -n airbyte <latest-discover-pod-name> -c connector-sidecar

Share the last 50 lines — the actual error message at the end will tell us what's really happening. Step 3: Check the server logs at the time of failure

kubectl logs -n airbyte <server-pod-name> --since=10m | grep -i "413\|error\|request"

------------------------- The knowledge sources do not document a scenario where 10 tables causes a genuine 413 payload size error. [MSSQL 413] At this point, the most likely explanation is that the

MICRONAUT_SERVER_MAX_REQUEST_SIZE

setting is not reaching the server pod. Please share the output of the

kubectl exec

env check and the tail of the discover pod logs so we can identify the actual root cause. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai do you think browser would be an issue i am using crome browser and have tried by creating new connection and destiantion but with same db? i thight some old cashe was causing issue currently i have triggerd new discovery to give you the logs you asked

The browser (Chrome) and browser cache are not the cause of the 413 error you're seeing. The 413 is happening server-side, deep in the Kubernetes pod logs:

Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large
    at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090)

This error occurs when the connector sidecar pod tries to send the discovered catalog back to the Airbyte API server — this is entirely a backend communication issue between pods, not anything related to your browser or browser cache. [MSSQL 413] Clearing your browser cache or switching browsers will have no effect on this error. ------------------------- While you wait for the new discovery logs Please run these two commands and share the output — they are the most critical checks right now: 1. Confirm the env var is actually inside the server container:

kubectl exec -n airbyte <server-pod-name> -- env | grep MICRONAUT

2. Get the tail of the new discover pod logs once it finishes:

kubectl get pods -n airbyte | grep postgres-discover
kubectl logs -n airbyte <latest-discover-pod-name> -c connector-sidecar | tail -50

The fact that even 10 tables fails strongly suggests

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is not actually applied to the running server container, and the

kubectl exec

command above will confirm this definitively. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai. pasting the output of the things u have asked 1) kubectl exec -n airbyte airbyte-server-5bbdbb9ff8-7qrkw -- env | grep MICRONAUT MICRONAUT_ENVIRONMENTS=control-plane MICRONAUT_SERVER_MAX_REQUEST_SIZE=104857600 2)

Sorry @Aswin, I encountered an error processing the file(s) you uploaded: File type is not supported

@kapa.ai. pasting the output of the things u have asked 1) kubectl exec -n airbyte airbyte-server-5bbdbb9ff8-7qrkw -- env | grep MICRONAUT MICRONAUT_ENVIRONMENTS=control-plane MICRONAUT_SERVER_MAX_REQUEST_SIZE=104857600 2)

Good progress! The env var is confirmed on the server pod:

MICRONAUT_SERVER_MAX_REQUEST_SIZE=104857600

That's 100MB — not 500MB as you mentioned trying earlier. If you intended to set 500MB, the value should be

524288000

. But more importantly, even 100MB should be more than enough for 10 tables. This means the

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is applied correctly, and the 413 with only 10 tables is not a payload size issue. Something else is causing the failure. ------------------------- What we need now: the discover pod logs (part 2 of your output) You mentioned you were pasting the output — it looks like the second part got cut off. Please share the output of:

kubectl get pods -n airbyte | grep postgres-discover
kubectl logs -n airbyte <latest-discover-pod-name> -c connector-sidecar | tail -80

Also check the server logs at the time of the failure:

kubectl logs -n airbyte airbyte-server-5bbdbb9ff8-7qrkw --since=15m | grep -i "413\|error\|request\|entity"

------------------------- Why this matters With 10 tables and 100MB limit confirmed on the server, the 413 should not be a size issue. The server logs may reveal what the actual rejection reason is — it could be a different endpoint, a different size limit, or a completely different error being misreported as 413. [MSSQL 413] Please paste the remaining logs you were sharing. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai. pasting the output of the things u have asked 1) kubectl exec -n airbyte airbyte-server-5bbdbb9ff8-7qrkw -- env | grep MICRONAUT MICRONAUT_ENVIRONMENTS=control-plane MICRONAUT_SERVER_MAX_REQUEST_SIZE=104857600 2) check the file i have given for logs

Sorry @Aswin, I encountered an error processing the file(s) you uploaded: Text file is too large (max 60K characters)

@kapa.ai. pasting the output of the things u have asked 1) kubectl exec -n airbyte airbyte-server-5bbdbb9ff8-7qrkw -- env | grep MICRONAUT MICRONAUT_ENVIRONMENTS=control-plane MICRONAUT_SERVER_MAX_REQUEST_SIZE=104857600 2) 2026-03-04 122800,970 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresSource(supportResumableFullRefresh):939 stream io.airbyte.protocol.models.v0.ConfiguredAirbyteStream@3741c7de[stream=io.airbyte.protocol.models.v0.AirbyteStream@24a887a0[name=woi_workorderrelationshipinter,jsonSchema={"type":"object","properties":{"customer_phone_number":{"type":"string"},"middle_initial":{"type":"string"},"completed_date":{"type":"number","airbyte_type":"integer"},"request_type01":{"type":"number","airbyte_type":"integer"},"clientlocale":{"type":"string"},"company3":{"type":"string"},"categorization_tier_1":{"type":"string"},"associations_id":{"type":"string"},"categorization_tier_2":{"type":"string"},"categorization_tier_3":{"type":"string"},"customer_first_name":{"type":"string"},"location_company":{"type":"string"},"priority":{"type":"number","airbyte_type":"integer"},"srmsregistryinstanceid":{"type":"string"},"support_group_name2":{"type":"string"},"vendor_assignee_groups_parent":{"type":"string"},"status":{"type":"number","airbyte_type":"integer"},"ztmpeventguid":{"type":"string"},"wo_type_field_21":{"type":"string"},"scheduled_end_date":{"type":"number","airbyte_type":"integer"},"wo_type_field_22":{"type":"string"},"wo_type_field_20":{"type":"string"},"wo_type_field_25":{"type":"number","airbyte_type":"integer"},"wo_type_field_26":{"type":"number","airbyte_type":"integer"},"wo_type_field_23":{"type":"string"},"srmsaoiguid":{"type":"string"},"requestor_id":{"type":"string"},"association_type01":{"type":"number","airbyte_type":"integer"},"wo_type_field_24":{"type":"number","airbyte_type":"integer"},"wo_type_field_29":{"type":"string"},"customer_organization":{"type":"string"},"wo_type_field_27":{"type":"number","airbyte_type":"integer"},"wo_type_field_28":{"type":"string"},"product_name__2_":{"type":"string"},"customer_last_name":{"type":"string"},"support_organization2":{"type":"string"},"form_name02":{"type":"string"},"submit_date":{"type":"number","airbyte_type":"integer"},"status_reason":{"type":"number","airbyte_type":"integer"},"srattachment":{"type":"string"},"assigned_to":{"type":"string"},"wo_type_field_10":{"type":"string"},"wo_type_field_11":{"type":"string"},"wo_type_field_14":{"type":"string"},"wo_type_field_15":{"type":"string"},"wo_type_field_12":{"type":"string"},"wo_type_field_13":{"type":"string"},"srinstanceid":{"type":"string"},"wo_type_field_18":{"type":"string"},"last_name":{"type":"string"},"wo_type_field_19":{"type":"string"},"wo_type_field_16":{"type":"string"},"wo_type_field_17":{"type":"string"},"product_cat_tier_3__2_":{"type":"string"},"actual_end_date":{"type":"number","airbyte_type":"integer"},"site":{"type":"string"},"workorderid":{"type":"string"},"work_order_id":{"type":"string"},"product_cat_tier_1_2_":{"type":"string"},"organization":{"type":"string"},"ci_reconid":{"type":"string"},"actual_start_date":{"type":"number","airbyte_type":"integer"},"wo_type_field_5":{"type":"string"},"last_modified_date":{"type":"number","airbyte_type":"integer"},"wo_type_field_6":{"type":"number","airbyte_type":"integer"},"wo_type_field_3":{"type":"string"},"wo_type_field_4":{"type":"string"},"wo_type_field_9":{"type":"number","airbyte_type":"integer"},"wo_type_field_7":{"type":"number","airbyte_type":"integer"},"wo_type_field_8":{"type":"number","airbyte_type":"integer"},"srid":{"type":"string"},"customer_department":{"type":"string"},"customer_middle_name":{"type":"string"},"asgrpid":{"type":"string"},"wo_type_field_1":{"type":"string"},"wo_type_field_2":{"type":"string"},"person_id":{"type":"string"},"lookup_keyword":{"type":"string"},"add_request_for_":{"type":"number","airbyte_type":"integer"},"wo_type_field_30":{"type":"string"},"request_id01":{"type":"string"},"business_service":{"type":"string"},"templateid":{"type":"string"},"support_organization":{"type":"string"},"instanceid":{"type":"string"},"ascpy":{"type":"string"},"customer_internet_e_mail":{"type":"string"},"phone_number":{"type":"string"},"aschg":{"type":"string"},"requested_by_person_id":{"type":"string"},"submitter":{"type":"string"},"product_model_version__2_":{"type":"string"},"description":{"type":"string"},"work_order_type":{"type":"number","airbyte_type":"integer"},"assignee_groups":{"type":"string"},"ci_datasetid":{"type":"string"},"cab_manager___change_co_ord__":{"type":"string"},"assignee_groups_parent":{"type":"string"},"customer_person_id":{"type":"string"},"company":{"type":"string"},"customer_company":{"type":"string"},"first_name":{"type":"string"},"scheduled_start_date":{"type":"number","airbyte_type":"integer"},"detailed_description":{"type":"string"},"record_id":{"type":"string"},"aslogid":{"type":"string"},"support_group_name":{"type":"string"},"product_cat_tier_2__2_":{"type":"string"},"request_id":{"type":"string"},"vendor_assignee_groups":{"type":"string"},"asorg":{"type":"string"},"asgrp":{"type":"string"}}},supportedSyncModes=[full_refresh, incremental],sourceDefinedCursor=<null>,defaultCursorField=[],sourceDefinedPrimaryKey=[],namespace=public,isResumable=<null>,additionalProperties={}],syncMode=full_refresh,cursorField=[],destinationSyncMode=overwrite,primaryKey=[],generationId=<null>,minimumGenerationId=<null>,syncId=<null>,additionalProperties={}] will not sync in resumeable full refresh mode. 2026-03-04 122800,971 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresUtils(isCdc):70 using CDC: true 2026-03-04 122801,872 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.c.i.b.IntegrationRunner(runInternal):224 Completed integration: io.airbyte.cdk.integrations.base.ssh.SshWrappedSource 2026-03-04 122801,872 [main] INFO i.a.w.i.VersionedAirbyteStreamFactory(internalLog$io_airbyte_airbyte_commons_worker):248 - INFO main i.a.i.s.p.PostgresSource(main):752 completed source: class io.airbyte.integrations.source.postgres.PostgresSource 2026-03-04 122801,874 [main] INFO i.a.c.ConnectorMessageProcessor(updateConfigFromControlMessage):281 - Checking for optional control message... 2026-03-04 122801,878 [main] INFO i.a.c.ConnectorMessageProcessor(setOutput):199 - Writing catalog result to API... 2026-03-04 122804,022 [main] ERROR i.a.c.ConnectorWatcher(handleException):200 - Error performing operation: io.airbyte.workers.exception.WorkerException io.airbyte.workers.exception.WorkerException: Unexpected error performing DISCOVER. The exit of the connector was: 0 at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:114) at io.airbyte.connectorSidecar.ConnectorWatcher.processConnectorOutput(ConnectorWatcher.kt:154) at io.airbyte.connectorSidecar.ConnectorWatcher.run(ConnectorWatcher.kt:79) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt:22) at io.airbyte.connectorSidecar.ApplicationKt.main(Application.kt) Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.setOutput(ConnectorMessageProcessor.kt:202) at io.airbyte.connectorSidecar.ConnectorMessageProcessor.run(ConnectorMessageProcessor.kt:108) ... 4 common frames omitted 2026-03-04 122804,154 [main] INFO i.a.c.ConnectorWatcher(failWorkload):342 - Failing workload decd338e-5647-4c0b-adf4-da0e75f5a750_5f655aa1-7cd8-44b7-a2d2-b4895a187b0b_0_discover. 2026-03-04 122804,418 [main] INFO i.a.c.ConnectorWatcher(exitInternalError):254 - Deliberately exiting process with code 1. [aamala@dbaasjump004 ~]$

This is very revealing. The

MICRONAUT_SERVER_MAX_REQUEST_SIZE=104857600

(100MB) is confirmed on the server pod, yet even 10 tables fails with 413. This means the 413 is not being rejected by the Airbyte server — it's being rejected by something in front of it, most likely the

airbyte-workload-api-server

pod, not

airbyte-server

. Look at the stack trace carefully:

at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090)

The connector sidecar is calling the Workload API / Source API, which may be a different service with its own size limit — not the main

airbyte-server

you've been configuring. [MSSQL 413] Step 1: Check the

workload-api-server

pod for the env var

kubectl exec -n airbyte airbyte-workload-api-server-65c5dc68d8-8v4qk -- env | grep MICRONAUT

If

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is missing or small on this pod, that's your root cause. Step 2: Add the setting to

workload-api-server

in

values.yaml

workload-api-server:
  extraEnvs:
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "524288000"  # 500MB

Then re-apply:

helm upgrade airbyte airbyte/airbyte --namespace airbyte -f values.yaml

Step 3: Verify after upgrade

kubectl exec -n airbyte <new-workload-api-server-pod-name> -- env | grep MICRONAUT

------------------------- The knowledge sources do not explicitly document the

workload-api-server

size limit configuration, but the stack trace clearly shows the 413 originates from

SourceApi.writeDiscoverCatalogResult

— which communicates with the workload API layer, not the main server. [MSSQL 413] This is the most likely explanation for why configuring

MICRONAUT_SERVER_MAX_REQUEST_SIZE

on

airbyte-server

alone has had no effect. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai global: airbyteUrl: https://airbyte.dbaas.testrun env_vars: HTTP_IDLE_TIMEOUT: 3600s # MICRONAUT_SERVER_MAX_REQUEST_SIZE: "524288000" # 500MB webapp: ingress: annotations: nginx.ingress.kubernetes.io/proxy-send-timeout: "3600" nginx.ingress.kubernetes.io/proxy-read-timeout: "3600" nginx.ingress.kubernetes.io/proxy-body-size: "50m" server: httpIdleTimeout: 20m extraEnv: - name: READ_TIMEOUT value: 30m - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE value: "524288000" # 500MB workload-api-server: extraEnvs: - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE value: "524288000" # 500MB is this right? any cahnges?

Your

values.yaml

looks mostly right, but there are a few things to fix: Issues to address 1.

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is commented out under

global.env_vars

— that's fine since you're setting it directly on the pods, but make sure it's intentional. 2.

server.extraEnv

should be

server.extraEnvs

(plural) — you're on Helm chart V1 (

airbyte-1.9.2

). The correct key is

extraEnvs

with an s. Using

extraEnv

(without the s) may be silently ignored. [Scaling Airbyte] 3.

workload-api-server.extraEnvs

uses the correct plural form ✅ — keep this as is. Corrected

values.yaml

global:
  airbyteUrl: https://airbyte.dbaas.testrun
  env_vars:
    HTTP_IDLE_TIMEOUT: 3600s

webapp:
  ingress:
    annotations:
      nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
      nginx.ingress.kubernetes.io/proxy-body-size: "500m"  # increase this too

server:
  httpIdleTimeout: 20m
  extraEnvs:                          # <-- plural (was extraEnv)
    - name: READ_TIMEOUT
      value: 30m
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "524288000"  # 500MB

workload-api-server:
  extraEnvs:
    - name: MICRONAUT_SERVER_MAX_REQUEST_SIZE
      value: "524288000"  # 500MB

Key changes •

server.extraEnv

→

server.extraEnvs

(plural, required for Helm chart V1) •

nginx.ingress.kubernetes.io/proxy-body-size

increased to

"500m"

to match the 500MB limit you're setting on the backend pods After applying

helm upgrade airbyte airbyte/airbyte --namespace airbyte -f values.yaml

Then verify both pods have the setting:

kubectl exec -n airbyte <server-pod-name> -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE
kubectl exec -n airbyte <workload-api-server-pod-name> -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE

Both should return

524288000

. [MSSQL 413] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai find this pod names first how to?

kubectl exec -n airbyte <server-pod-name> -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE
kubectl exec -n airbyte <workload-api-server-pod-name> -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE

Run this to list all pods in the

airbyte

namespace and find the exact names:

kubectl get pods -n airbyte

From your previous output, the pod names are already visible: • Server pod:

airbyte-server-5bbdbb9ff8-7qrkw

(or whatever the current name is after the latest upgrade) • Workload API server pod:

airbyte-workload-api-server-65c5dc68d8-8v4qk

(or current name) So the commands to run are:

kubectl exec -n airbyte airbyte-server-5bbdbb9ff8-7qrkw -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE
kubectl exec -n airbyte airbyte-workload-api-server-65c5dc68d8-8v4qk -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE

> Note: After running

helm upgrade

, the pod names will change (the random suffix changes on restart). Always run

kubectl get pods -n airbyte

first to get the current pod names before running the

exec

commands. [Developing Locally] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, [aamala@dbaasjump004 ~]$ kubectl exec -n airbyte airbyte-workload-api-server-6fb5f99bc-fr2gj -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE [aamala@dbaasjump004 ~]$ kubectl exec -n airbyte airbyte-server-6859684c46-sthkv -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE no ouput any other commands?

The fact that both pods return no output confirms that

MICRONAUT_SERVER_MAX_REQUEST_SIZE

is not being applied to either pod after your latest

helm upgrade

. The

values.yaml

changes are not taking effect. Diagnose why the values aren't being applied Step 1: Confirm what values Helm is actually using

helm get values airbyte -n airbyte

This shows what values Helm has recorded for your current release. Check if

workload-api-server.extraEnvs

and

server.extraEnvs

appear there. Step 2: Check if the correct values file was used in the upgrade

helm get manifest airbyte -n airbyte | grep -A5 "MICRONAUT_SERVER_MAX_REQUEST_SIZE"

This shows the actual rendered Kubernetes manifests. If the env var doesn't appear here, Helm never rendered it into the deployment. Step 3: Manually patch the pods as a temporary workaround While you investigate the Helm issue, you can patch the deployments directly:

kubectl set env deployment/airbyte-server -n airbyte MICRONAUT_SERVER_MAX_REQUEST_SIZE=524288000
kubectl set env deployment/airbyte-workload-api-server -n airbyte MICRONAUT_SERVER_MAX_REQUEST_SIZE=524288000

Then verify:

kubectl exec -n airbyte <new-server-pod-name> -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE
kubectl exec -n airbyte <new-workload-api-server-pod-name> -- env | grep MICRONAUT_SERVER_MAX_REQUEST_SIZE

> Note: This direct patch will be overwritten the next time you run

helm upgrade

, so it's only a temporary test to confirm whether the env var on

workload-api-server

is the actual fix. Step 4: After patching, retry discovery Trigger a new discovery on your 10-table source and check if the 413 is resolved. If it succeeds, that confirms the

workload-api-server

was the missing piece, and you can then focus on getting the Helm values to apply correctly. [MSSQL 413] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, what is this error 413

The 413 Request Entity Too Large error in your Airbyte context means that the HTTP request payload being sent is too large for the server to accept. Here's specifically what's happening in your case: 1. The Postgres source connector successfully completes the schema discovery (finds all your tables and their schemas). 2. The connector sidecar pod then tries to send the discovered catalog back to the Airbyte API by calling

writeDiscoverCatalogResult

. 3. That HTTP request is rejected with 413 because the catalog payload exceeds the server's configured maximum request size. [MSSQL 413] The exact error in your logs is:

Caused by: org.openapitools.client.infrastructure.ClientException: Client error : 413 Request Entity Too Large
    at io.airbyte.api.client.generated.SourceApi.writeDiscoverCatalogResult(SourceApi.kt:1090)

Why it happens in your setup • Your database has a very large number of tables with wide schemas (many columns each). • The JSON catalog representing all those tables and their schemas becomes a very large payload. • The Airbyte API server (and/or the workload API server) has a default maximum request size that this payload exceeds. [MSSQL 413] What controls the limit The relevant setting is

MICRONAUT_SERVER_MAX_REQUEST_SIZE

, which needs to be applied to both: •

airbyte-server

pod •

airbyte-workload-api-server

pod Based on our conversation, the env var is currently not being applied to either pod despite your

values.yaml

changes, which is why even 10 tables still fails. The immediate next step is to patch the deployments directly to test:

kubectl set env deployment/airbyte-server -n airbyte MICRONAUT_SERVER_MAX_REQUEST_SIZE=524288000
kubectl set env deployment/airbyte-workload-api-server -n airbyte MICRONAUT_SERVER_MAX_REQUEST_SIZE=524288000

👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.