Take "CoreV1API_patchNodeStatus"as an example: fix #160 (https://github.com/kubernetes-client/c/pull/160) appends "force=0" to Patch HTTP Request. Then we will get an Error in the response as below.

"causes": [
    {
        "reason": "FieldValueForbidden",
        "message":"Forbidden: may not be specified for non-apply patch","field":"force"
    }
]

BTW, in answer to the question from brendandburns above

Why is this exception returning 504 (timeout) instead of 410 (gone)

I can only guess, but I think when the requested RV is larger than what the API Server is currently aware of, returning "gone" was probably considered wrong. Since "gone" implies "it was here, but it's not here any more". That's different from this situation, where we need a response that says "It's not here yet".

@yue9944882 What's the current status of this? It looks like it got closed without being fixed?

@yue9944882 now i solve it by rewriting the constructor. If the startup log can increase the timeout warning, i think programers should decide how to set the timeout according to the production environment.

build(deps-dev): bump jackson-annotations from 2.14.1 to 2.14.2

Bumps jackson-annotations from 2.14.1 to 2.14.2.

• Release notes
• Commits

updated-dependencies:

• dependency-name: com.fasterxml.jackson.core:jackson-annotations dependency-type: direct:development update-type: version-update:semver-patch ...

Signed-off-by: dependabot[bot] support@github.com

Merge pull request #2544 from kubernetes-client/dependabot/maven/com.fasterxml.jackson.core-jackson-annotations-2.14.2

build(deps-dev): bump jackson-annotations from 2.14.1 to 2.14.2

Bumps jackson-annotations from 2.14.1 to 2.14.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dependabot[bot], yue9944882

The full list of commands accepted by this bot can be found here.

The pull request process is described here

• ~~OWNERS~~ [yue9944882]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

/ok-to-test

the default read timeout for apiClient is 0, so now the assertion will fail if a user overrides a non-zero read timeout here. if i remember correctly, the point of having a zero assertion here is to prevent users from restarting watch connection too frequently e.g. a 30s read timeout means that the informer will refresh the watch connection and the local cache every 30s which can be a big burden for the client memory. due to the limitation of okhttp library, the apiClient cannot set different read timeouts for short-running and long-running api calls, generally, a watch call is expected to last about 5-10 minutes, so as an alternative, we can relax the assertion to readTimeout >= 10min, @coderYii do you think that will work for your case?

Add a rule to block empty YAML constructors.

Switch to SafeConstructor for YAML everywhere.

Merge pull request #2541 from brendandburns/r0.17

[Cherry-pick] Add a rule to block empty YAML constructors.

Add a rule to block empty YAML constructors.

Switch to SafeConstructor for YAML everywhere.

Merge pull request #2542 from brendandburns/r0.16

[Cherry-pick] Add a rule to block empty YAML constructors.

Add a rule to block empty YAML constructors.

Switch to SafeConstructor for YAML everywhere.

Merge pull request #2543 from brendandburns/r0.15

[Cherry-pick] Add a rule to block empty YAML constructors.

Cherry pick of #2533

Cherry pick of #2533

Cherry-pick of #2533

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, yue9944882

The full list of commands accepted by this bot can be found here.

The pull request process is described here

• ~~OWNERS~~ [brendandburns,yue9944882]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, yue9944882

The full list of commands accepted by this bot can be found here.

The pull request process is described here

• ~~OWNERS~~ [brendandburns,yue9944882]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: brendandburns, yue9944882

The full list of commands accepted by this bot can be found here.

The pull request process is described here

• ~~OWNERS~~ [brendandburns,yue9944882]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment