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
This file contains hidden or 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
Disallows requesting a null TTL in a task, as that isn't in the spec for requests (only for responses) - this was an oversight in the initial implementation.
Groups all task-related fields into a single object to unflatten the extra fields a bit.
One topic from #1275 that doesn't have any changes here is the ? vs. undefined thing - I took a look through the task interfaces and we use ? consistently, which I think is the right approach. Let me know if there's any disagreement on this, and I can adjust things appropriately.
How Has This Been Tested?
Adjusted unit tests for the grouping, and added some unit tests for disallowing null in requests.
Breaking Changes
Both of these are breaking changes, and are therefore intended to be part of the v2 SDK. I think it would be reasonable to backport one or both commits to the v1 branch (especially given this is clearly marked as experimental), but I'm defaulting to v2 here.
Types of changes
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)
The specification only allows the server to return a null TTL, it doesn't allow the client to request that.
This is intentional, as it forces clients to make a choice betwen a specific TTL or not caring what the TTL is, rather than defaulting to keeping tasks forever all the time.
Allowing the requested value to be null was an implementation oversight that diverged from the spec.
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
@KKonstantinov the field grouping is something we aren't going to backport (it's a breaking change for essentially a convenience), but I'm less sure about the null thing - I suppose we can backport that part, since it is just a bug. Will open a PR.
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.
nullTTL in a task, as that isn't in the spec for requests (only for responses) - this was an oversight in the initial implementation.Motivation and Context
#1275
One topic from #1275 that doesn't have any changes here is the
?vs.undefinedthing - I took a look through the task interfaces and we use?consistently, which I think is the right approach. Let me know if there's any disagreement on this, and I can adjust things appropriately.How Has This Been Tested?
Adjusted unit tests for the grouping, and added some unit tests for disallowing
nullin requests.Breaking Changes
Both of these are breaking changes, and are therefore intended to be part of the v2 SDK. I think it would be reasonable to backport one or both commits to the v1 branch (especially given this is clearly marked as experimental), but I'm defaulting to v2 here.
Types of changes
Checklist
Additional context
Closes #1275