Added AddressManagerTracingLambda#183
Added AddressManagerTracingLambda#183FedericaMoschese wants to merge 4 commits intofeature/PN-16895-epicfrom
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a new AWS Lambda function called AddressManagerTracingLambda for processing address manager tracing events. The Lambda is configured to consume messages from an SQS queue and integrates with the existing infrastructure.
Changes:
- Added CloudFormation resources for the Lambda function, including security groups, IAM roles, policies, and alarm configurations
- Created Lambda function code structure with entry point and event handler
- Configured SQS event source mapping to trigger the Lambda from a tracing input queue
Reviewed changes
Copilot reviewed 8 out of 9 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| scripts/aws/cfn/storage.yml | Added log group configuration for the new Lambda function |
| scripts/aws/cfn/microservice.yml | Added Lambda function infrastructure including IAM roles, security groups, SQS event source mapping, and related resources |
| scripts/aws/cfn/microservice-dev-cfg.json | Added Lambda runtime configuration parameter |
| functions/addressManagerTracingLambda/src/app/eventHandler.js | Created empty event handler function for Lambda processing logic |
| functions/addressManagerTracingLambda/sonarqube-scanner.js | Added SonarQube scanner configuration for code quality analysis |
| functions/addressManagerTracingLambda/sonar-project.properties | Added SonarQube project properties for test coverage and exclusions |
| functions/addressManagerTracingLambda/package.json | Added npm package configuration with dependencies and test scripts |
| functions/addressManagerTracingLambda/index.js | Created Lambda entry point that delegates to event handler |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 9 out of 10 changed files in this pull request and generated 8 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| @@ -0,0 +1,6 @@ | |||
| sonar.sources=src/app | |||
| sonar.tests=src/test | |||
| sonar.test.inclusions=src/**/__tests__/** | |||
There was a problem hiding this comment.
The test inclusion pattern doesn’t match the project’s test location (src/test/**/*.test.js), so Sonar may not detect tests/coverage correctly. Update sonar.test.inclusions to match your actual test path/pattern (or remove it if sonar.tests=src/test is sufficient).
| sonar.test.inclusions=src/**/__tests__/** | |
| sonar.test.inclusions=src/test/**/*.test.js |
| "build": "npm prune --production && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/*' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", | ||
| "test": "nyc --reporter=html --reporter=text mocha './src/test/**/*.test.js' --recursive --timeout=5000 --exit -r dotenv/config", | ||
| "coverage": "nyc report --reporter=lcov", | ||
| "sonar": "node sonarqube-scanner.js -Dsonar.login=${SONAR_TOKEN}" |
There was a problem hiding this comment.
sonarqube-scanner.js does not parse CLI -D... arguments, so -Dsonar.login=${SONAR_TOKEN} is likely ignored and authentication may fail. Pass the token via the JS options object (e.g., set sonar.login/sonar.token from process.env.SONAR_TOKEN) or use the scanner’s supported environment-variable mechanism.
| "sonar": "node sonarqube-scanner.js -Dsonar.login=${SONAR_TOKEN}" | |
| "sonar": "node sonarqube-scanner.js" |
| }, | ||
| () => process.exit() |
There was a problem hiding this comment.
Unconditionally calling process.exit() can mask scanner failures and force a zero exit code depending on how errors are surfaced. Prefer propagating failures (e.g., set a non-zero process.exitCode on error / don’t force exit) so CI correctly fails when the scan fails.
| }, | |
| () => process.exit() | |
| } |
| "main": "index.js", | ||
| "scripts": { | ||
| "test-build": "npm run-script test && npm run-script coverage && npm run-script sonar && npm run-script build", | ||
| "build": "npm prune --production && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/*' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", |
There was a problem hiding this comment.
The zip exclude pattern -x './src/test/*' only excludes immediate children of src/test and can still include nested test files/folders, inflating the deployment artifact. Use a recursive exclude (e.g., exclude ./src/test/**) so all tests are omitted from the Lambda zip.
| "build": "npm prune --production && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/*' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", | |
| "build": "npm prune --production && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/**' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", |
| "main": "index.js", | ||
| "scripts": { | ||
| "test-build": "npm run-script test && npm run-script coverage && npm run-script sonar && npm run-script build", | ||
| "build": "npm prune --production && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/*' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", |
There was a problem hiding this comment.
npm prune --production is increasingly discouraged in favor of --omit=dev workflows. Consider switching to npm prune --omit=dev (or using npm ci --omit=dev in a clean build directory) to align with modern npm behavior.
| "build": "npm prune --production && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/*' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", | |
| "build": "npm prune --omit=dev && rm -f ./function.zip && zip -r ./function.zip . -x './src/test/*' -x '*.md' -x '*.env' -x './coverage/*' -x './.nyc_output/*' -x './.scannerwork/*'", |
| @@ -0,0 +1,3 @@ | |||
| exports.handleEvent = async (event) => { | |||
There was a problem hiding this comment.
The handler currently returns a constant true and ignores the input event, which makes it hard to understand intended behavior and can hide integration issues at runtime. If this is a scaffold, add at least minimal event validation / logging / TODO notes or implement the core flow before wiring infra triggers.
| exports.handleEvent = async (event) => { | |
| exports.handleEvent = async (event) => { | |
| if (event == null) { | |
| console.warn('handleEvent invoked with null or undefined event'); | |
| } else { | |
| // Basic logging to aid debugging and integration validation. | |
| console.log('handleEvent received event:', JSON.stringify(event)); | |
| } | |
| // TODO: Implement core event processing logic once event schema and behavior are defined. |
| it('should return success for a valid event', async () => { | ||
| const event = {}; | ||
| const context = {}; | ||
| const result = await handleEvent(event, context); | ||
|
|
||
| expect(result).to.equal(true); | ||
| }); |
There was a problem hiding this comment.
This test only asserts the current stub behavior (always true) and doesn’t validate any real event shape/branching or the exported Lambda entrypoint (index.js). Once real logic is added, extend tests to cover expected inputs, error paths, and (if applicable) SQS batch semantics.



No description provided.