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
[ESO] Add flag to allow ESO consumers to opt-out of highly random UIDs #198287
[ESO] Add flag to allow ESO consumers to opt-out of highly random UIDs #198287
Changes from 9 commits
27caca1
18caf7f
f4fa81d
9cde66d
b99d3ee
0122276
e13c10e
b8f7605
5032efd
356880d
2e362b8
67ca7d0
58d2b2d
b84429c
c5d7b10
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.
Tip
Optional and not that important, but I’m wondering if we should throw an error here if type isn’t registered (
isEncryptableType(type) !== true
)? It’s unlikely to happen in practice since we expect consumers of this API to callisEncryptableType
first, but it still feels a bit odd that this function would returntrue
for non-ESOs if someone mistakenly uses it in this context.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.
@azasypkin That's a good point! I think i'll address it in a follow-up PR.
I was also thinking about the scenario where a type explicitly opts out but no ID is provided during creation. In it's current implementation, a random ID will be created but I was wondering if it should behave differently?
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.
Thanks!
Hmm, I think the current behavior is correct and works the same for both ESO and non-ESO saved objects. I interpret
enforceRandomId
as "prevent consumers from explicitly specifying non-random IDs, but keep the default behavior if they don’t specify IDs".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.
++ Yeah, if an type has opted out of enforcing random IDs but an ID is not provided during creation, a random ID should be generated.
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 augment the unit tests in
saved_objects_encryption_extension.test.ts
to cover this function as well.Trivial nit: