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 Cloud Trace team wants to make it easy for users to send trace IDs along with various API calls, effectively just adding a special header (X-Cloud-Trace-Context) with an opaque ID.
The issue is that this ID will vary across requests, which presents a bit of an issue in that whole concurrency thing...
Anyway -- we need to find a way to allow users to...
Set custom headers to be forwarded along with each API request to Google
Configure those headers in one place (ie, not as arguments to each method as people don't want to change all their code for this)
Make sure that it's obvious how to do this the right way (ie, avoid giving people a gun and aiming it at their feet -- which setTraceContext in my example might do...)
👍 I imagine most of the time, users might just want their own custom UA, so we should support: (edit: maybe that doesn't make sense actually? Either way, they could manipulate whatever part of the request they want:)
As far as allowing per-request control, like "got a request for resource X, attach a custom header while we download it then remove it after", maybe we can go even one level deeper:
varopts={projectId: 'my-project-id'};varstorage=gcloud.storage(opts);// Need to set a custom headervarnewOpts=extend({},opts,{decorateRequest: function(reqOpts){reqOpts.headers['X-Cloud-Trace-Context']='...';}});varnewStorage=gcloud.storage(newOpts);storage.getBuckets();// no custom header sentnewStorage.getBuckets();// custom header sent
gcloud as well as any service object will accept the decorateRequest function.
And as a side note, with the upcoming switch to promises this could potentially provide a nice interface for failed request logic, assuming we followed angular's api.
Activity
stephenplusplus commentedon Oct 26, 2015
👍 I imagine most of the time, users might just want their own custom UA, so we should support: (edit: maybe that doesn't make sense actually? Either way, they could manipulate whatever part of the request they want:)
Then overriding per service should be pretty straightforward:
As far as allowing per-request control, like "got a request for resource X, attach a custom header while we download it then remove it after", maybe we can go even one level deeper:
All of these have the decorated request options, while any other service (Dataset) or object (Bucket, File, Topic, etc) wouldn't be touched.
Regarding the gist, I put together how this would look: https://gist.github.com/jgeewax/3b351d3522fdf061bdea
stephenplusplus commentedon Oct 26, 2015
Another option:
stephenplusplus commentedon Nov 23, 2015
Let's go with this:
gcloudas well as any service object will accept thedecorateRequestfunction.Sound okay?
callmehiphop commentedon Nov 23, 2015
Reminds me of angular interceptors, a similar interface to that could be nice
And as a side note, with the upcoming switch to promises this could potentially provide a nice interface for failed request logic, assuming we followed angular's api.
stephenplusplus commentedon Nov 23, 2015
Looks cool to me. 👍
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore(deps): update codecov/codecov-action action to v4 (#916)
chore: linting (#916)
chore: api logs codeowners (#916)
feat: add a close() method to PubSub, and a flush() method to Topic/P…
chore: release 1.7.0 (#933)
chore: release 1.7.0 (#933)