-
Notifications
You must be signed in to change notification settings - Fork 15.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PHP: Deprecation message for "return_immediately" is thrown which is impossible to fix #13428
Comments
https://github.com/googleapis/googleapis/blob/master/google/pubsub/v1/pubsub.proto#L1227-L1228 this field is marked deprecated. If you wish to not have the deprecation warning, you need to mark the field as non-deprecated. |
The issue is not that the field is deprecated, but that some internal call is being done which triggers the deprecation warning, without any way to avoid that. Please consider reopening the issue, as it is not fixed. |
Ah, I misunderstood. Is there a way to suppress specific calls to deprecated methods at the callsite? |
Well you can suppress these kinds of warnings in PHP, but that would either mean disabling all deprecated warnings, or doing some hacks to only disable them for this particular use case. Neither are really preferable IMO: I think when you're specifically not using this option, the library should not warn about using it. |
Maybe it's not the best way, but I got rid of this error from the logs by setting the transport method to $client = new PubSubClient(['transport'=>'rest']); |
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment. This issue is labeled |
Issue is still active. |
I see two potential solutions here:
public function getSomeDeprecatedField()
{
if ($this->some_deprecated_field !== null) {
@trigger_error('some_deprecated_field is deprecated.', E_USER_DEPRECATED);
}
return $this->some_deprecated_field;
} @fowles I'm happy to submit a PR for either of these if you think they're acceptable. |
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment. This issue is labeled |
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment. This issue is labeled |
I can also take this on, if the solution is approved! |
@fowles can you give a 👍 or 👎 in this so we can either fix it, or find another solution to it? |
@fowles has taken on expanded scope. I'm taking on his role on the protobuf team. Experience with doc comments is that they are ignored -- a reasonable amount of log nagging is a good nudge in the right direction. Option 2 (triggering deprecation logging only when set), looks good from a protobuf perspective. @bshaffer @pkruithof I leave it to the two of you to decide who implements. |
We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please add a comment. This issue is labeled |
@pkruithof I'll take a look! |
@pkruithof I've made my own PR for this, because there were some tricky implementation details. See #17788 |
@bshaffer Any update on this? I've checked your PR and it seems it has not yet been merged. Having the same issue with deprecated warning on every pull requests. |
It is actually merged, it seems. I thought there wasn't a release with this change yet, but it seems it's available since v29.0: https://github.com/protocolbuffers/protobuf/releases/tag/v29.0 🎉 [edit] spoke too soon, because it's not landed in the PubSub library yet I think... |
You're right, we haven't upgraded to protobuf v29 yet, we are still on v25 https://github.com/googleapis/googleapis/blob/master/WORKSPACE#L152 |
Do you have an estimate when this will be upgraded? |
@pkruithof not yet but I'll look into it |
See googleapis/google-cloud-php#5350
@pkruithof has reported the following, which seems to be an error in the Protobuf package. The function
getReturnImmediately
is being called internally without any way (as far as we can tell) to prevent it from happening:Because the
return_immediately
option has been deprecated some time ago, this produces a deprecation log on every pull request:At first I thought to submit a workaround for this, so that the deprecation is only shown when the option is set to
true
(false
is the default):The setter should still always trigger the deprecation, so you still see it when you use the option and set it to
false
.However, then I noticed that this code is generated. So I don't think this is possible, unless there's a way to customize generated classes like this?
In any case, I would very much like to be able to remove this deprecation from our processes, as it's polluting our logs, making them harder to read. Is there another way to go here?
Here is the stack trace
The text was updated successfully, but these errors were encountered: