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.
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
Add versioning support in durabletask-dotnet(phase1) #295
base: main
Are you sure you want to change the base?
Add versioning support in durabletask-dotnet(phase1) #295
Changes from 11 commits
380c622
1976de6
4e1f8cb
f6162ff
d564c79
d9298d0
60c1341
fc44a4a
5b1b2b2
cb86ecd
83bc227
f1619b1
0045ced
2172e96
5c3ad58
7912d46
d015d3e
87b15e1
6ecfde1
220fb2d
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good opportunity for pattern matching. Can replace this if/else statements with:
Also while we are at it, can replace the other ctor with:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should consider adding FromString semantics. But I wonder if that will be a breaking change? We have not restricted what characters can be used in a task name before this.
This change is going to introduce a confusing behavior:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the implicit operator be updated to parse out the version?
I'm not super concerned about the breaking change since 99+% of .NET users should be relying on the function name, which already can't have special characters. However, we can take a look at Kusto data to confirm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes the implicit operator would be changed to call
FromString
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should have a discussion on what separator to use. I like
@
, as that is what we have used for distributed tracing to indicate the version - and ":" was used to separate the task type:{task_type}:{name}@{version}
However, we already use
@
to separate entity name and key - will that be an issue? Or is that a good thing to use@
as a separator in both for consistency.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using
@
could break entity ID parsing. Looking at this code, I can see that entity IDs take the form of{name}@{key}
and the code that parses this looks for the first instance of@
to separate the name from the key. If we inject a version into the name, we make it{name}@{version}@{key}
, and the key for entities will be parsed as{version}@{key}
instead of{key}
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cgillum yeah I am trying to think through how that behaves. One thing is that it is a separate type for entities. We have a few options:
@
for separator. Entity instance IDs can then look like@{entity}@{version}@{key}
(or we can do key first, then version). RISK: keys could already contain@
. This could break those instances.@@
to indicate this entity has a version field. So@myEntity@some@key
-> no version field.@@myEntity@version@some@key
-> version field present.@{entity}?{version}@{key}
(or key first). RISK: this character could already be used by customers in name or keyThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Want to clarify that I am not opposed to a different separator char for version. We haven't officially GA'd distributed tracing v2, so we could update that spec with the new separator. But what one exactly?
Some that I have ruled out myself in the past:
/
- avoided this so it wasn't confused with HTTP routes in distributed tracing%
- often used for encoding special chars, so wanted to avoid that*
- wild card, wanted to avoid that.!
- used in netherite for partition targeting. We are looking to also support that in other backends.:
- used in distributed tracing to separate the task-type. ie:orchestration:name@version
oractivity:name@version
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we merge this PR first and then open a new issue to trace and update the separator after we have a final decision?
Because today is my last day, I'm afraid that I can't continue to update the code in this PR because of permissions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cgillum @jviau please have a look at this PR and let's make the final decision.