Open vobarian opened 1 week ago
Exemption Request
Features must contain a change to a README file. Features must contain a change to an integration test file and the resulting snapshot.
Just adding originId; other existing origins I checked do not document these properties in the readme and do not include customizing originId in the integration tests.
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository
The pull request linter fails with the following errors:
❌ Features must contain a change to a README file.
❌ Features must contain a change to an integration test file and the resulting snapshot.
PRs must pass status checks before we can provide a meaningful review.
If you would like to request an exemption from the status checks or clarification on feedback, please leave a comment on this PR containing Exemption Request
and/or Clarification Request
.
✅ A exemption request has been requested. Please wait for a maintainer's review.
Issue # (if applicable)
Closes #31468.
Reason for this change
OriginGroup allows users to specify a custom originId for better readability and descriptiveness compared to the auto generated IDs.
Description of changes
Adding originId to OriginGroupProps was straightforward. Unfortunately, the existing design of the Distribution binding interfaces makes some assumptions that don't model the underlying domain accurately. Specifically, while it is convenient for all origins to implement IOrigin so they can be used with any Behavior, the IOrigin interface specifies a bind method that returns an OriginBindConfig having a CfnDistribution.OriginProperty and a failoverConfig. This is not an accurate way to model origin groups, as it treats a group as a singular origin (is-a relationship) that has a failover origin. Actually, an origin group is not a singular origin, but has a primary origin and failover origin. The difference is the current model implies only 2 origin IDs, while the latter more accurate model implies 3. I would have to make a lot of breaking changes to these interfaces to fix this design, so I just added an originGroupId property to OriginBindConfig to provide a way to return the 3rd ID needed. I consider it a bit messy but could not find another way without completely redesigning the binding object model.
Additionally, the duplicate ID checking is now more complicated. Since the existing model incorrectly treats the primary origin as the originId of the group, there was already a separate originGroupId property in the BoundOrigin. I guess that was a previous workaround for the problems with the model. As a result, adding an OriginGroup requires 4 comparisons with each existing Origin (cross product of originId and originGroupId, as there is really only one ID scope and they must be unique).
Description of how you validated changes
Unit tests added in origin-group.test.ts.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license