Closed bshaffer closed 3 months ago
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 rest
$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 inactive
because the last activity was over 90 days ago.
Issue is still active.
I see two potential solutions here:
trigger_error
warning, and say that the @deprecated
tag in phpdoc will suffice trigger_error
in a conditional so it only happens if the field has been set. This would look something like this:
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 inactive
because the last activity was over 90 days ago.
Issue is still active.
Either solution presented by @bshaffer looks good to me, @fowles can we move this issue along? Since we're nearing the 2-year mark since the start of it π
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 inactive
because the last activity was over 90 days ago.
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 inactive
because the last activity was over 90 days ago. This issue will be closed and archived after 14 additional days without activity.
The issue is still active, however I made a start for the fix in #17607, only I need some help getting it finished. I was hoping @bshaffer could find some time so we can (finally) get this issue resolved π π€
@pkruithof I'll take a look!
@pkruithof I've made my own PR for this, because there were some tricky implementation details. See https://github.com/protocolbuffers/protobuf/pull/17788
See https://github.com/googleapis/google-cloud-php/issues/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