Keep original VCAP-Request-ID for re-enqueued ReoccurringJobs #3208
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
All background jobs are wrapped in a LoggingContextJob that stores the
original VCAP-Request-ID and ensures that the same ID is used (e.g. for
logs) while performing the job.
For ReoccurringJobs, this capability got lost when the job was
re-enqueued. Adding the next job to the queue did not happen as part of
the 'perform' method, but in the 'success' hook. So by using the
'with_request_id_set' method also for the 'success' hock, the
re-enqueued job keeps the original VCAP-Request-ID.
The effect can be seen when looking at logs with source
cc.service_broker.v2.http_client. When polling for the last operation
state of a provisioned service instance, the VCAP-Request-ID was only
set for the initial 'fetch' request (which was done in the same job as
the 'provision' request). With this change, all subsequent state polls
are also logged with "data":{"request_guid":"original-guid",...}.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
All background jobs are wrapped in a
LoggingContextJobthat stores the original VCAP-Request-ID and ensures that the same ID is used (e.g. for logs) while performing the job.For
ReoccurringJobs, this capability got lost when the job was re-enqueued. Adding the next job to the queue did not happen as part of theperformmethod, but in thesuccesshook. So by using thewith_request_id_setmethod also for thesuccesshock, the re-enqueued job keeps the original VCAP-Request-ID.The effect can be seen when looking at logs with source
cc.service_broker.v2.http_client. When polling for the last operation state of a provisioned service instance, the VCAP-Request-ID was only set for the initial 'fetch' request (which was done in the same job as the 'provision' request). With this change, all subsequent state polls are also logged with"data":{"request_guid":"original-guid",...}.I have reviewed the contributing guide
I have viewed, signed, and submitted the Contributor License Agreement
I have made this pull request to the
mainbranchI have run all the unit tests using
bundle exec rakeI have run CF Acceptance Tests