Add support of parsing job body format according to the job id version #225
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
Currently, we store the job payload in Redis without any encoding, so it's possible to extend more fields for job, like attributes etc. To mitigate this issue, we introduce the version prefix for the job id to identify different job payload formats. And use the length to tell if it's a legacy id or not since the ulid's id is a fixed length string(26 chars). That said, we will return the value as job body directly if the length is 26. Otherwise, decode it as JSON format. And to avoid introducing breaking changes during the upgrade stage, we add a new HTTP header: Enable-Job-Version to enable this feature. The new job format would be enabled only if the header `Enable-Job-Version: yes` was explicitly passed in the publish request. So that we can smoothly support new job payload format by upgrading the server first, and enable it in client side since then.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #225 +/- ##
==========================================
- Coverage 56.23% 51.84% -4.40%
==========================================
Files 38 25 -13
Lines 2984 1846 -1138
==========================================
- Hits 1678 957 -721
+ Misses 1090 746 -344
+ Partials 216 143 -73
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
3 tasks
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.
Currently, we store the job payload in Redis without any encoding,
so it's possible to extend more fields for a job, like attributes, etc.
To mitigate this issue, we introduce the version prefix for the job id
to identify different job payload formats. Use the length to tell
if it's a legacy id or not since the ulid's id is a fixed-length
string(26 chars). That said, we will return the value as job body
directly if the length is 26. Otherwise, decode it in JSON format.
Also, to avoid introducing breaking changes during the upgrade stage,
we add a new HTTP header: Enable-Job-Version to enable this feature.
The new job format would be enabled only if the header
Enable-Job-Version: yeswas explicitly passed in the publish request. So that we can smoothly
support the new job payload format by upgrading the server first, and enabling
it on client side since then.