feat(lambda-event-sources): starting position timestamp for kafka
Issue # (if applicable)
Closes #31808
Reason for this change
It was impossible to start consuming a Kafka topic from a specific point in time.
Description of changes
The user may now set startingPositionTimestamp to ManagedKafkaEventSource and SelfManagedKafkaEventSource to start consuming a Kafka topic from a specific point in time.
Lambda and CloudFormation have supported the functionality for a while, and other stream event sources like KinesisEventSource already had a CDK implementation for it, so there's nothing new under the sky — just expanding it to cover sources we are using :)
Description of how you validated changes
The change is tested by adding similar unit tests to other event sources supporting this functionality.
Checklist
- [x] My code adheres to the CONTRIBUTING GUIDE and DESIGN GUIDELINES
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
could you please add a new GH issue as a Feature request, and link it to this issue.
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. To keep this PR from being closed, please continue work on it. If not, it will automatically be closed in a week.
Agreed with @moelasmar, this seems like a feat to me - @nikovirtala can you please add an integ test and README documentation on this?
README is clear, but creating the integration test for this is a lot of work:
~1) there are no existing integration tests for any other Event Source Mappings~ 2) ~testing~ asserting Kafka Event Source Mapping requires creating an MSK cluster or such, which is not as trivial as creating a simple resource like DynamoDB Table (I hope there is something I can borrow from the MSK module, if one exist)
Exemption Request
- testing Kafka Event Source Mapping requires creating an MSK cluster or such, which is not as trivial as creating a simple resource like DynamoDB Table (I hope there is something I can borrow from the MSK module, if one exist)
Ok, the MSK module is in alpha state, and even that doesn't have an integration test that would create a topic and messages to the topic — which would be required to test this feature 😞
I doubt that creating all that is too much for me.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 82.38%. Comparing base (
7c1870f) to head (129d236). Report is 1 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #31439 +/- ##
=======================================
Coverage 82.38% 82.38%
=======================================
Files 120 120
Lines 6955 6955
Branches 1173 1173
=======================================
Hits 5730 5730
Misses 1120 1120
Partials 105 105
| Flag | Coverage Δ | |
|---|---|---|
| suite.unit | 82.38% <ø> (ø) |
Flags with carried forward coverage won't be shown. Click here to find out more.
| Components | Coverage Δ | |
|---|---|---|
| packages/aws-cdk | ∅ <ø> (∅) |
|
| packages/aws-cdk-lib/core | 82.38% <ø> (ø) |
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
~It seems there are zero integration tests in this module. So, can anyone change this module before there is one?~ 🤔
sorry @nikovirtala for not coming back to this PR. I see that you already handled the integ testing point. I left one minor comment.
sorry @nikovirtala for not coming back to this PR. I see that you already handled the integ testing point. I left one minor comment.
No worries! I was stuck in thinking that the integration test requirement meant something else than it actually does — I had set the bar "a little" too high in my mind 😅
This PR has been in the CHANGES REQUESTED state for 3 weeks, and looks abandoned. Note that PRs with failing linting check or builds are not reviewed, please ensure your build is passing
To prevent automatic closure:
- Resume work on the PR
- OR request an exemption by adding a comment containing 'Exemption Request' with justification e.x "Exemption Request:
" - OR request clarification by adding a comment containing 'Clarification Request' with a question e.x "Clarification Request:
"
This PR will automatically close in 14 days if no action is taken.
Thank you @nikovirtala for contributing this PR, please let us know if you're still interested continue with this feature implementation, to prevent auto closure.
Thank you @nikovirtala for contributing this PR, please let us know if you're still interested continue with this feature implementation, to prevent auto closure.
I have a lot of interest in getting this feature available but I don't know if I have time to deal with the constantly changing "requirements" from changing reviewers — it should be enough to get things merged if currently used conventions are followed.
Thank you @nikovirtala for your contribution, all comments are addressed now, will work on getting this merged in.
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).
AWS CodeBuild CI Report
- CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
- Commit ID: 129d236f9d4ff0cb80fcbc6ddf0460ed4178699d
- Result: SUCCEEDED
- Build Logs (available for 30 days)
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).
Comments on closed issues and PRs are hard for our team to see. If you need help, please open a new issue that references this one.