[JingHao-Leon]

What broke

The hand-written *_and_poll convenience methods for load balancer listeners and pools did not accept some of the parameters that the generated API methods support, so those API fields could not be used through the convenience methods:

Convenience method	Missing parameter
cloud.load_balancers.listeners.create_and_poll	default_pool_id
cloud.load_balancers.listeners.update_and_poll	admin_state_up
cloud.load_balancers.listeners.delete_and_poll	delete_default_pool
cloud.load_balancers.pools.update_and_poll	admin_state_up

Passing any of them raised a TypeError before a request was made:

TypeError: ListenersResourceCustomMixin.update_and_poll() got an unexpected keyword argument 'admin_state_up'

admin_state_up is the documented way to enable/disable a listener or a pool ("When set to false, the resource is disabled and will not process traffic"), so there was no way to turn a listener or pool off through update_and_poll.

The AsyncGcore variants of the same four methods were affected identically.

Root cause

The *_and_poll helpers are hand-written mixins, not codegen output — the file headers state: "Custom code. This file is not generated and is preserved across codegen runs." Each helper re-declares the parameter list of the generated method it wraps, and those re-declarations had drifted from the generated signatures:

• src/gcore/resources/cloud/load_balancers/listeners_custom.py:34 — create_and_poll declared no default_pool_id, while the generated create declares it at src/gcore/resources/cloud/load_balancers/listeners.py:73.
• src/gcore/resources/cloud/load_balancers/listeners_custom.py:143 — update_and_poll declared no admin_state_up, while the generated update declares it at src/gcore/resources/cloud/load_balancers/listeners.py:175.
• src/gcore/resources/cloud/load_balancers/listeners_custom.py:107 — delete_and_poll declared no delete_default_pool, while the generated delete declares it at src/gcore/resources/cloud/load_balancers/listeners.py:347.
• src/gcore/resources/cloud/load_balancers/pools/pools_custom.py:138 — update_and_poll declared no admin_state_up, while the generated update declares it at src/gcore/resources/cloud/load_balancers/pools/pools.py:192.

Because each helper forwards only the parameters it declares, the field never reached the API.

The change

Declare the missing parameters in the helpers and forward them to the generated method, in both the sync and the async mixin. The new parameters are keyword-only and default to omit, so existing calls are unaffected.

• src/gcore/resources/cloud/load_balancers/listeners_custom.py — default_pool_id on create_and_poll, admin_state_up on update_and_poll, delete_default_pool on delete_and_poll (sync + async).
• src/gcore/resources/cloud/load_balancers/pools/pools_custom.py — admin_state_up on update_and_poll (sync + async).

How to verify

The new regression test in tests/api_resources/cloud/test_and_poll_custom.py calls each of the four helpers with the parameter and asserts that it reaches the API request (in the JSON body, or in the query string for delete_default_pool).

Before the fix:

$ python -m pytest tests/api_resources/cloud/test_and_poll_custom.py -k forwards_supported_params -q
...
E   TypeError: ListenersResourceCustomMixin.update_and_poll() got an unexpected keyword argument 'admin_state_up'
...
8 failed in 4.43s

After the fix:

$ python -m pytest tests/api_resources/cloud/test_and_poll_custom.py -k forwards_supported_params -q
........                                                                 [100%]
8 passed in 5.54s

The whole hand-written *_and_poll test suite:

$ python -m pytest tests/api_resources/cloud/test_and_poll_custom.py tests/api_resources/cloud/test_update_and_poll_noop_custom.py -q
271 passed in 4.66s

The rest of the unit suite is unchanged compared to the base commit — the same 4 failures before and after, and they are the pre-existing ones that need the mock API server on 127.0.0.1:4010 (httpx.ConnectError: [Errno 61] Connection refused):

$ python -m pytest tests/test_transform.py tests/test_response.py tests/test_qs.py tests/test_files.py \
    tests/test_models.py tests/test_client.py tests/test_required_args.py tests/test_streaming.py \
    tests/test_extract_files.py tests/test_utils -q
4 failed, 472 passed, 2 skipped in 5.71s

Lint and types:

$ ruff check .
All checks passed!

$ mypy .
Found 10 errors in 5 files (checked 1335 source files)

The 10 mypy errors are pre-existing and unrelated to this change — the identical count is reported on the base commit 75c6b55f (missing optional httpx_aiohttp extra, nox stubs, and pydantic signature differences in this environment).

CI

gh pr checks reports no results for this branch. The workflow runs exist but are held at the upstream approval gate: 5 runs were created for the head SHA 016b3d22 (4 distinct workflows — CI twice, Fossa, Release Doctor, Trunk sync lock), all with conclusion action_required and 0 jobs executed, i.e. they are waiting for a maintainer to approve running them.

So there is no upstream test result for this branch yet, and the verification numbers above are from local runs.

Fixes #67

This change was prepared with the assistance of an AI coding agent.

[pedrodeoliveira]

Thanks @JingHao-Leon, the fix is correct and the regression tests are very useful.

This repository is published from our private staging repository, and changes only flow one way at this time. So we've brought your commits into a staging repository PR unchanged, with you as their author. It'll be in the next release.

We are also adding a test that fails CI whenever an *_and_poll helper falls behind the method it wraps, so this kind of gap gets caught automatically from now on. I'm closing this PR and will update #67 when the changes are in the production repository.