@kapa.ai How can I fix :

No streams found with name [xxx] and namespace [null].

on PosgtreSQL source using CDC

The knowledge sources don't contain a direct, definitive fix for this exact error on a PostgreSQL CDC source, but based on the available information, here are some relevant findings and suggestions: Possible Causes & Fixes 1. Namespace/Schema Configuration Issues A forum post describes a very similar symptom — streams being skipped with "not in the source" errors — that was traced back to having multiple schemas configured in the source. The workaround was: [Postgres stream not found] • Create a new source with only one schema defined. • Create a new connection using that single-schema source. • If you need multiple schemas, be aware that switching between them can leave problematic metadata that causes streams to be skipped. 2. Connector Version Bug A similar issue (streams not discovered) was caused by a bug in a specific Postgres connector version and was fixed in a subsequent release. [Failure to discover streams] • Try upgrading your Postgres source connector to the latest available version. 3. Platform Version The

namespace=null

variant of this error has also been seen in destination connectors and was linked to old platform versions with known bugs around namespace handling. [S3 Data Lake stream not found] • Ensure your Airbyte platform is up to date. 4. After a Connector Upgrade If the error appeared after upgrading the Postgres connector, stale state may be the cause. One workaround reported was resetting the connection state (or in extreme cases, dropping the Airbyte internal database to force a full reset). [Stream ignored after connector update] • Try performing a full reset of the affected connection in the Airbyte UI. ------------------------- > Note: The knowledge sources do not contain a single definitive fix specifically for

namespace=null

on a PostgreSQL CDC source. If the above steps don't resolve the issue, I'd recommend opening a GitHub issue with your connector version, platform version, and full logs for further investigation. 👍 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 how can I reach "getstreamproperties" from my bastion VM over Airbyte deployed on GKE ?

To call the

getStreamProperties

(

GET /streams

) endpoint from a bastion VM against an Airbyte instance deployed on GKE, you need to ensure network connectivity between your bastion and the Airbyte server. Here's what the knowledge sources tell us: 1. Expose Airbyte via Ingress (Recommended) Set up a Kubernetes Ingress (e.g., NGINX or AWS ALB) that routes traffic to the Airbyte server service. The ingress routes the

/

path to

airbyte-server-svc

on port

8001

, which handles API calls. [Ingress docs]

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: airbyte-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "false"
spec:
  ingressClassName: nginx
  rules:
    - host: airbyte.example.com  # replace with your host
      http:
        paths:
          - backend:
              service:
                name: airbyte-airbyte-server-svc
                port:
                  number: 8001
            path: /
            pathType: Prefix

Once the ingress is up, your bastion VM (assuming it's in the same VPC or has network access to the GKE cluster) can call:

GET https://airbyte.example.com/v1/streams?sourceId=<UUID>&destinationId=<UUID>

Make sure

global.airbyteUrl

in your

values.yaml

matches the ingress URL. [Implementation Guide] 2. Port Forwarding (Simple/Temporary) If you just need temporary access from the bastion, you can use `kubectl port-forward`:

kubectl port-forward svc/airbyte-airbyte-server-svc 8001:8001 --namespace airbyte

Then call the API locally on the bastion:

GET http://localhost:8001/v1/streams?sourceId=<UUID>&destinationId=<UUID>

> Note: Port forwarding requires a persistent terminal session. For production use, the ingress approach is preferred. 3. Networking Considerations • Airbyte does not currently support most service meshes (e.g., Istio). [Implementation Guide] • Verify that firewalls or IAM permissions are not blocking pod-to-pod or external communication. • If your bastion and GKE cluster share the same VPC, you may be able to reach the service directly without a public ingress, but you'll still need to work with your infra team to allow the appropriate network access. [GKE networking] 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.