You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The PullRequest.maxMessages is a mandatory field, if we don't provide it we get this error:
{
"error": {
"code": 400,
"message": "A required argument is missing in the request: (argument=\"max_messages\").",
"status": "INVALID_ARGUMENT",
}
}
The PubSub API design we drafted considers maxMessages an optional option, we must either fix this (by transforming it into a mandatory parameter) or use a default value if the user does not explicitly provide it. /cc @eschapira@aozarov thoughts?
Is this for calling the pull method explicitly or for the callback version?
I would say that for explicit pulls it is required, and for callback there
should be a default (set it to 100, no hard data on why that's a good
value, but sounds reasonable to me).
Yes, this is for calling the pull method explicitly.
For the pull method with callback the idea was to allow the user to limit
the maximum number of concurrent callbacks. 100 sounds like a reasonable
value in this case.
On 9 May 2016 16:01, "eschapira" notifications@github.com wrote:
Is this for calling the pull method explicitly or for the callback version?
I would say that for explicit pulls it is required, and for callback there
should be a default (set it to 100, no hard data on why that's a good
value, but sounds reasonable to me).
Activity
eschapira commentedon May 9, 2016
Is this for calling the pull method explicitly or for the callback version?
I would say that for explicit pulls it is required, and for callback there
should be a default (set it to 100, no hard data on why that's a good
value, but sounds reasonable to me).
On Mon, May 9, 2016 at 9:52 AM, Marco Ziccardi notifications@github.com
wrote:
Emilio Schapira
mziccard commentedon May 9, 2016
Yes, this is for calling the pull method explicitly.
For the pull method with callback the idea was to allow the user to limit
the maximum number of concurrent callbacks. 100 sounds like a reasonable
value in this case.
On 9 May 2016 16:01, "eschapira" notifications@github.com wrote:
mziccard commentedon May 11, 2016
Fixed in #996
feat: add a DeploymentResourcePool API resource_definition (#997)
chore(main): release 3.2.0 (#1017)
chore(main): release 4.8.2 (#997)
chore(main): release 0.124.14 (#997)
chore(main): release 2.8.25-SNAPSHOT (#997)
chore(deps): update dependency com.google.cloud:libraries-bom to v26.…
build(deps): update releasetool version for release scripts (#1768) (#…
chore: Generated snippets should not be owned by samples reviewers (#…
chore: Generated snippets should not be owned by samples reviewers (#…
chore: enable auto release in java (#1349) (#997)
chore: enable auto release in java (#1349) (#997)