Skip to content
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

Response header hooks #689

Merged
merged 3 commits into from
May 3, 2023
Merged

Response header hooks #689

merged 3 commits into from
May 3, 2023

Conversation

apparentlymart
Copy link
Contributor

@apparentlymart apparentlymart commented Apr 25, 2023

The API for this client library is focused on returning the primary data associated with each API response, which typically means just the body of the response.

Sometimes clients will also need to react to cross-cutting metadata such as expiration times, cache control guidance, and rate limiting information, which isn't a direct part of the data being requested but can nonetheless affect the behavior of the client. This information is typically returned in HTTP response header fields.

To give access to this information without a breaking change to the API, this uses the context.Context API to allow the rare caller that needs it to register a hook through which it will be notified about the response header in any case where the request succeeded enough for there to be one.

Most clients will not need this facility, which justifies the light abuse of the context.Context API for passing in this optional hook, even though this isn't the sort of cross-cutting concern context.Context should typically be used for.


The goal of introducing this now is to improve hashicorp/terraform#32983 so that the Terraform Cloud / Enterprise API can return a new response header signaling its preferred state snapshot interval, thereby creating a compromise between creating no intermediate snapshots at all vs. creating so many intermediate snapshots as to overwhelm the storage of Terraform Enterprise customers and run across potential race conditions in Terraform Cloud.

This is a compromise to have a sort of relief valve in case of problems. This does not necessarily replace other efforts to store and present intermediate snapshots in a better way in Terraform Cloud, although it could potentially allow working on those with less urgency.

@apparentlymart apparentlymart added the enhancement New feature or request label Apr 25, 2023
@apparentlymart apparentlymart requested a review from a team as a code owner April 25, 2023 18:55
@apparentlymart apparentlymart self-assigned this Apr 25, 2023
@apparentlymart
Copy link
Contributor Author

apparentlymart commented Apr 25, 2023

I can see that the "errcheck" lint has failed, but the failure doesn't seem to have generated any information about the source location of the problem. 🤔

It looks like the job is intended to generate annotations for the source code to mark where the problems are -- I see it asking the tool to generate its results in a GitHub Actions-specific format -- but no annotations have appeared. I'm not sure what exactly that lint failure is referring to.

brandonc
brandonc previously approved these changes Apr 26, 2023
Copy link
Collaborator

@brandonc brandonc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a nice solution! A test infrastructure dependency (run tasks mock) is down right now so I will merge this manually once the linter passes

request_hooks.go Outdated Show resolved Hide resolved
The API for this client library is focused on returning the primary data
associated with each API response, which typically means just the body
of the response.

Sometimes clients will also need to react to cross-cutting metadata such
as expiration times, cache control guidance, and rate limiting
information, which isn't a direct part of the data being requested but
can nonetheless affect the behavior of the client. This information is
typically returned in HTTP response header fields.

To give access to this information without a breaking change to the API,
this uses the context.Context API to allow the rare caller that needs it
to register a hook through which it will be notified about the response
header in any case where the request succeeded enough for there to be one.

Most clients will not need this facility, which justifies the light abuse
of the context.Context API for passing in this optional hook, even though
this isn't the sort of cross-cutting concern context.Context should
typically be used for.
@apparentlymart apparentlymart merged commit 5ed1d9b into main May 3, 2023
@apparentlymart apparentlymart deleted the matkins/response-header-hook branch May 3, 2023 20:53
@github-actions
Copy link

github-actions bot commented May 3, 2023

Reminder to the contributor that merged this PR: if your changes have added important functionality or fixed a relevant bug, open a follow-up PR to update CHANGELOG.md with a note on your changes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants