feat: add support for setting x-request-id header #606
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds mediocre support for setting request ids to support request debugging.
Methods on
censys.search.{CensysHosts|CensysCerts}
don't support configuring the underlying request object on each call. Given that**kwargs
is used to glob additional search params on most methods, I didn't see a clean and consistent way to support setting one-off request options through the query methods themselves.Support for setting the x-request-id header is implemented by adding a property to the
CensysAPIBase
class, where updates will mutate the request objects headers, so that the next request will include the assigned request-id value.This leads to an awkward, though functional, usage pattern:
This ux is definitely not ideal, but it makes the feature available quickly with minimal changes to the package interfaces. I figure this is tolerable for now since it's only meant for debugging.