-
Notifications
You must be signed in to change notification settings - Fork 364
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
fix: [M3-8090] - OMC - Update scope.region type to reflect new API changes #10451
Conversation
Coverage Report: ✅ |
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 for tackling this @abailly-akamai!
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 for the details description 📝 !
Confirmed I was able to create an access key with the flag off using alpha ✅
@@ -72,7 +72,7 @@ export const getDefaultScopes = (buckets: ObjectStorageBucket[]): Scope[] => | |||
bucket_name: thisBucket.label, | |||
cluster: thisBucket.cluster, | |||
permissions: 'none' as AccessType, | |||
region: thisBucket.region ?? '', | |||
region: thisBucket.region ?? null, |
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.
The API spec states 11.1.1
If "regions" is present, but its value is "null" or an empty list, the server must reject the request.
I would suggest we could remove the regions field in this case instead making it required with null value.
region: thisBucket.region ?? undefined
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.
see my comment, you need to align with the API team on this
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.
If regions
is a new field for OMC, wouldn't it makes sense to just completely omit it here?
region: thisBucket.region ?? null, |
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 why ideally we need to two types and two payloads (depending on the flag value)
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 shouldn't be adjusting types based on a feature's availability. It weakens type safety.
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, that's a great point. I'm curious how people handle this problem in general
The only thing that comes to mind is maintaining two separate type interfaces.
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 we've been doing those "temporary" types often, then clean them up when the feature is in production.
I put an cafe item to discuss this. the overhead of doing two interfaces/payloads is extra work but worth it IMO. some features take a long time to see the day so the chances are something like this can happen when API amends its contract without considering it a breaking change
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.
In this case with two interfaces It also leads to rewrite or duplicate most of the API OBJ methods in API v4.
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.
Also a great point @cpathipa
Static types are hard 😣
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.
They are. Not to mention we are "lying" about what true types are in our SDK by doing it this way
@cpathipa have you checked the threads and confirmed with the API team? You may be dealing with outdated specs or miscommunication between parties. Also
are we talking about the same thing here?
|
@cpathipa feel free to update this PR as you see fit for your project and the upcoming release |
@abailly-akamai We should be good for now for addressing the issue of having empty string in the regions field. |
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.
Able to create limited keys ✅
Code review ✅
export interface ScopeRequest extends Omit<Scope, 'cluster'> { | ||
// @TODO OBJ Multicluster: Omit 'region' as well when API changes get released to prod | ||
cluster?: string; | ||
region?: string; | ||
region: string | null; |
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.
closing since this breaking change has since been reverted in this APIv4 PR |
Description 📝
In alpha, we're seeing a payload error when POSTing to the object-storage/keys.
This is due to this PR having been merged to alpha and adding strictness to what is passed to the body of the endpoint in the absence of
regions_allowed
flag (Object MultiCluster)The fact this was not caught is due to two reasons:
Changes 🔄
Scope.region
required and nullableTarget release date 🗓️
5/13/2024
Preview 📷
Screen.Recording.2024-05-08.at.22.20.50.mov
Screen.Recording.2024-05-08.at.22.20.01.mov
How to test 🧪
Prerequisites
Reproduction steps
Verification steps (verify in both ALPHA & PROD)
As an Author I have considered 🤔
Check all that apply