Secret Manager `list_secrets` silently returns empty when both `organization_id` and `project_id` are set

Start at SecretV1Beta1API.list_secrets and list_secrets_all, then trace how Client injects default_organization_id into requests. Reproduce the project-scoped listing with request logging and compare behavior when the organization ID is omitted; done means the intended handling of both scope parameters is implemented or clearly documented and covered by a regression test.

Description

SecretV1Beta1API.list_secrets (and list_secrets_all) returns an empty result set with HTTP 200 — no error — when the request includes both organization_id and project_id, even though matching secrets exist and the same request without organization_id returns them correctly.

The Client auto-fills default_organization_id from the profile/config on every request. Since list_secrets also accepts an explicit project_id (or falls back to default_project_id), nearly every call ends up sending both parameters — silently breaking listing for anyone who authenticates via a project-scoped API key (created for a single Project, not the whole Organization), which is a documented/recommended way to scope credentials.

Reproduction

from scaleway import Client
from scaleway.secret.v1beta1 import SecretV1Beta1API

client = Client.from_config_file_and_env()  # picks up default_organization_id + default_project_id
api = SecretV1Beta1API(client)
                                                                                                                                                    
r = api.list_secrets(scheduled_for_deletion=False, project_id=client.default_project_id)
print(r.total_count)  # -> 0

Enabling request logging shows the outgoing request includes both IDs:

GET https://api.scaleway.com/secret-manager/v1beta1/regions/fr-par/secrets?organization_id=<ORG_ID>&project_id=<PROJECT_ID>&scheduled_for_deletion=False

Calling the same endpoint directly with curl, omitting organization_id, returns the expected secrets:

curl -H "X-Auth-Token: $SCW_SECRET_KEY"
"https://api.scaleway.com/secret-manager/v1beta1/regions/fr-par/secrets?project_id=<PROJECT_ID>&scheduled_for_deletion=false"
# -> {"secrets": [...], "total_count": 9}

Re-adding organization_id to that same curl request reproduces the empty result:

curl -H "X-Auth-Token: $SCW_SECRET_KEY"
"https://api.scaleway.com/secret-manager/v1beta1/regions/fr-par/secrets?organization_id=<ORG_ID>&project_id=<PROJECT_ID>&scheduled_for_deletion=false"
# -> {"secrets": [], "total_count": 0}

So this looks like API-side behavior (the two filters may be ANDed against an internal scope in a way that a project-scoped key can't satisfy when organization_id is present), but the SDK makes it very easy to hit unknowingly, since organization_id is injected automatically and silently, with no error/warning that the combination yields zero rows.

Environment

• scaleway SDK version: 2.11.0
• Python: 3.12
• Auth: project-scoped API key (via scw config file / SCW_ACCESS_KEY + SCW_SECRET_KEY)

Expected behavior

Either:

1. The SDK should not auto-send organization_id when an explicit (or default) project_id is already being used for a request, or
2. The API should return an explicit error (e.g. 403) instead of an empty 200 when the org/project combination can't be satisfied, or
3. This should be documented so it's discoverable without reverse-engineering.

Workaround

Explicitly clear client.default_organization_id = None before calling list_secrets/list_secrets_all when authenticating with a project-scoped key.