Releases: aws-powertools/powertools-lambda-dotnet
1.9.1
Summary
In this release we fix an issue that was causing a System.InvalidCastException exception when decorating with the Tracing attribute generic methods that would be called with different T as parameters or return T.
Thank you @Kuling for reporting the issue.
using Amazon.Lambda.APIGatewayEvents;
using Amazon.Lambda.Core;
using AWS.Lambda.Powertools.Tracing;
[assembly: LambdaSerializer(typeof(Amazon.Lambda.Serialization.SystemTextJson.DefaultLambdaJsonSerializer))]
namespace MyFunction
{
public interface ISampleService
{
Task<T> LoadAsync<T>(T query);
}
[Tracing]
public class SampleService : ISampleService
{
public async Task<T> LoadAsync<T>(T query)
{
return default;
}
}
[Tracing]
public class Function
{
public async Task<APIGatewayProxyResponse> FunctionHandlerAsync(APIGatewayProxyRequest request, ILambdaContext context)
{
var target = new SampleService();
await target.LoadAsync<double>(3.4);
await target.LoadAsync<int>(5); // Bug
return null;
}
}
}Changes
📜 Documentation updates
🐛 Bug and hot fixes
🔧 Maintenance
This release was made possible by the following contributors:
Contributors
Assets 2
1.9.0
Summary
With this release, we add feature to existing Parameters to retrieve values from AWS AppConfig.
using AWS.Lambda.Powertools.Parameters;
using AWS.Lambda.Powertools.Parameters.AppConfig;
public class Function
{
public async Task<APIGatewayProxyResponse> FunctionHandler
(APIGatewayProxyRequest apigProxyEvent, ILambdaContext context)
{
// Get AppConfig Provider instance
IAppConfigProvider appConfigProvider = ParametersManager.AppConfigProvider
.DefaultApplication("MyApplicationId")
.DefaultEnvironment("MyEnvironmentId")
.DefaultConfigProfile("MyConfigProfileId");
// Retrieve a single configuration, latest version
IDictionary<string, string?> value = await appConfigProvider
.GetAsync()
.ConfigureAwait(false);
//Working with feature flags
// Check if feature flag is enabled
var isFeatureFlagEnabled = await appConfigProvider
.IsFeatureFlagEnabledAsync("MyFeatureFlag")
.ConfigureAwait(false);
if (isFeatureFlagEnabled)
{
// Retrieve an attribute value of the feature flag
var strAttValue = await appConfigProvider
.GetFeatureFlagAttributeValueAsync<string>("MyFeatureFlag", "StringAttribute")
.ConfigureAwait(false);
// Retrieve another attribute value of the feature flag
var numberAttValue = await appConfigProvider
.GetFeatureFlagAttributeValueAsync<int>("MyFeatureFlag", "NumberAttribute")
.ConfigureAwait(false);
}
}
}Changes
🌟New features and non-breaking changes
AWS.Lambda.Powertools.Logging - 1.5.1
AWS.Lambda.Powertools.Metrics - 1.6.1
AWS.Lambda.Powertools.Tracing - 1.4.1
AWS.Lambda.Powertools.Parameters - 1.3.0
AWS.Lambda.Powertools.Idempotency - 1.1.1
AWS.Lambda.Powertools.BatchProcessing - 1.1.1
📜 Documentation updates
🔧 Maintenance
- chore: Update nuget examples (#565) by @hjgraca
- chore: update package versions for examples (#564) by @hjgraca
- chore: Update version for release 1.9.0 (#563) by @amirkaws
- chore: Update NuGet packages to the latest (#561) by @amirkaws
- chore: Update examples to latest release (#555) by @hjgraca
This release was made possible by the following contributors:
Contributors
Assets 2
1.8.5
Summary
In this release we added a "global" exception handler to Logging utility, so that when using the utility the exceptions inside are not sent to the client and break their applications. Instead we write the error message to the logs so the client can act on it.
We also added support for dotnet 8. Now Powertools supports dotnet 6 and dotnet 8, we build packages for both versions.
Changes
AWS.Lambda.Powertools.Logging - 1.5.0
AWS.Lambda.Powertools.Tracing - 1.4.0
AWS.Lambda.Powertools.Metrics - 1.6.0
AWS.Lambda.Powertools.Parameters - 1.2.0
AWS.Lambda.Powertools.Idempotency - 1.1.0
AWS.Lambda.Powertools.BatchProcessing - 1.1.0
📜 Documentation updates
- chore: Update batch-processing docs (#547) by @hjgraca
- chore(docs): fix upper snake case to camel case. (#548) by @H1Gdev
- chore: Update tracing.md - Auto-disable when not running in AWS Lambda environment (#544) by @hjgraca
- docs: we made this section update (#536) by @sliedig
🐛 Bug and hot fixes
🔧 Maintenance
- chore: Update batch-processing docs (#547) by @hjgraca
- chore(docs): fix upper snake case to camel case. (#548) by @H1Gdev
- chore: dotnet 8 support (#542) by @hjgraca
- chore(deps): bump gitpython from 3.1.37 to 3.1.41 (#539) by @dependabot
- chore(deps): bump jinja2 from 3.1.2 to 3.1.3 (#540) by @dependabot
- chore: Update tracing.md - Auto-disable when not running in AWS Lambda environment (#544) by @hjgraca
This release was made possible by the following contributors:
1.8.4
Summary
In this release we are excited to announce the General Availability of Batch Processing utility.
Batch Processing
The batch processing utility handles partial failures when processing batches from Amazon SQS, Amazon Kinesis Data Streams, and Amazon DynamoDB Streams.
Key features
- Reports batch item failures to reduce number of retries for a record upon errors
- Simple interface to process each batch record
- Bring your own batch processor
- Parallel processing
Problem Statement
When using SQS, Kinesis Data Streams, or DynamoDB Streams as a Lambda event source, your Lambda functions are triggered with a batch of messages.
If your function fails to process any message from the batch, the entire batch returns to your queue or stream. This same batch is then retried until either condition happens first: a) your Lambda function returns a successful response, b) record reaches maximum retry attempts, or c) when records expire.
With this utility, batch records are processed individually – only messages that failed to be processed return to the queue or stream for a further retry.
Getting started
To get started add the NuGet package
dotnet add package AWS.Lambda.Powertools.BatchProcessing
Example of processing batches from SQS using Lambda handler decorator in three stages:
- Decorate your handler with BatchProcessor attribute
- Create a class that implements ISqsRecordHandler interface and the HandleAsync method.
- Pass the type of that class to RecordHandler property of the BatchProcessor attribute
- Return BatchItemFailuresResponse from Lambda handler using SqsBatchProcessor.Result.BatchItemFailuresResponse
Changes
📜 Documentation updates
🔧 Maintenance
- chore: Update version for batch GA (#532) by @hjgraca
- chore: Update examples idempotency (#528) by @hjgraca
This release was made possible by the following contributors:
@hjgraca and @lachriz-aws
1.8.3
Summary
In this release we are happy to announce the General Availability of Idempotency utility 🚀.
The Idempotency utility provides a simple solution to convert your Lambda functions into idempotent operations which are safe to retry.
During developer preview we have taken a lot of feedback. Better documentation, support for Idempotency InProgressExpiration timestamp, register the Lambda context in your handler.
Idempotency 1.0.0 Nuget package
🌟Key features
- Prevent Lambda handler function from executing more than once on the same event payload during a time window.
- Use DynamoDB as a persistence layer for state with bring your own persistence store provider.
- Select a subset of the event as the idempotency key using JMESPath expressions.
- Payload validation to provide an additional JMESPath expression to specify which part of the event body should be validated against previous idempotent invocations.
- Set a time window in which records with the same payload should be considered duplicates
- Expires in-progress executions if the Lambda function times out halfway through
Implementation example
Here is an example on how you register the Lambda context in your handler:
Lambda request timeout diagram
Quick links: 📜 Documentation | ⬇️ NuGet | 🐛 Bug Report
Changes
📜 Documentation updates
- chore: Update version and docs for Idempotency GA (#525) by @hjgraca
- chore: update examples for 1.8.2 release (#523) by @hjgraca
🐛 Bug and hot fixes
🔧 Maintenance
- chore: Update version and docs for Idempotency GA (#525) by @hjgraca
- chore: update examples for 1.8.2 release (#523) by @hjgraca
- chore: add e2e tests for idempotency method (#513) by @hjgraca
This release was made possible by the following contributors:
1.8.2
Summary
In this minor release we are adding support for a new environment variable to configure the log level in Logging utility.
You can now configure the log level of for Logger using the new environment variable: AWS_LAMBDA_LOG_LEVEL.
Setting the log level now follows this order:
AWS_LAMBDA_LOG_LEVELenvironment variable- Setting the log level in code using
[Logging(LogLevel = )] POWERTOOLS_LOG_LEVELenvironment variable
We have also added a new section to the docs to highlight the new behaviour.
New versions
Logging: 1.4.4
Metrics: 1.5.3
Changes
🌟New features and non-breaking changes
🐛 Bug and hot fixes
📜 Documentation updates
🔧 Maintenance
- chore: Update version for 1.8.2 (#518) by @hjgraca
- chore: Update examples for release 1.8.1 (#510) by @hjgraca
This release was made possible by the following contributors:
1.8.1
Summary
In this release we are happy to introduce two new converters for DateOnly and TimeOnly types. These are not supported by default on .NET 6 but will be included in Powertools.
We also fixed two bugs reported on the metrics utility.
- Do not throw exception when decorating a non Lambda handler method
- Do not throw exception when Metadata uses and existing metrics key
- Do not throw exception on second invocation when using Metadata
Version updates
Changes
🌟New features and non-breaking changes
🐛 Bug and hot fixes
- fix: Metrics throws exception when using AddMetadata (#505) by @hjgraca
- fix: Metrics throws exception when decorating non handler methods (#499) by @hjgraca
🔧 Maintenance
- chore: Update projects readme for nuget (#495) by @hjgraca
- chore: Update Batch Processing examples. Update all dependencies (#493) by @hjgraca
This release was made possible by the following contributors:
1.8.0
Summary
In this release we are happy to announce the first developer preview for the new Batch Processing utility 🚀. The batch processing utility handles partial failures when processing batches from Amazon SQS, Amazon Kinesis Data Streams, and Amazon DynamoDB Streams.
Check the documentation for how to get started with Batch Processing utility.
This utility is currently in developer preview and is intended strictly for feedback and testing purposes and not for production workloads. The version and all future versions tagged with the -preview suffix should be treated as not stable. Until this utility is General Availability we may introduce significant breaking changes and improvements in response to customers feedback.
🌟Key features
- Reports batch item failures to reduce number of retries for a record upon errors
- Simple interface to process each batch record
- Bring your own batch processor
- Parallel processing
Implementation examples
Amazon SQS processor
Amazon Kinesis Data Streams processor
Amazon DynamoDB Streams processor
This release was made possible by the following contributors:
@lachriz-aws, @hjgraca, and @amirkaws
Release 1.7.1
Summary
In this release we fix a bug that was introduced in the build of the latest release.
This issue caused all utilities to not work when decorating a Lambda handler, the reason was AspectInjector dll was not present as a reference for the NuGet package of the utilities.
We immediately detect the issue in our manual tests, and unlisted the affected versions from NuGet.
TLDR:
To prevent this from happening
- We have included E2E tests in GitHub build for the examples
- We have included a test that guarantees that we are using version 2.8.1 of AspectInjector
- We have included tests in our internal build system that run examples tests on non-released nuget packages
The issue demonstrated bellow:
With missing dependencies
With correct dependencies
🐛 Bug and hot fixes
🔧 Maintenance
This release was made possible by the following contributors:
1.7.0
Summary
In this release we are please to announce the removal of the Common dependency and Nuget package 🎉 and introducing NuGet Central Package Management (i.e. with Directory.Packages.props).
All utilities updated:
- AWS.Lambda.Powertools.Logging - 1.3.0
- AWS.Lambda.Powertools.Tracing - 1.3.0
- AWS.Lambda.Powertools.Metrics - 1.4.0
- AWS.Lambda.Powertools.Parameters - 1.1.0
- AWS.Lambda.Powertools.Idempotency - 0.2.0-preview
Utilities have a dependency on the AWS.Lambda.Powertools.Common project.
When the utility is compiled and packaged into a nuget package the AWS.Lambda.Powertools.Common is a dependency.
This behaviour is causing Diamond dependency issues in the project.
To address this we copy the required files to each utility and make them completely isolated. This allows the client to not have to worry about dependencies between utilities and AWS.Lambda.Powertools.Common.
There is no need to delete the AWS.Lambda.Powertools.Common project but link the files in other projects, this will make it more readable in the solution explorer and makes maintenance easier because it's all in a single project.
TLDR
- Add
Directory.Build.propsandDirectory.Build.targetsmore info- These two files allows us to modify all csproj files in the solution or where the files are placed in the folder structure
- Those files were added to the
srcfolder. They modify all csproj in that folder where all utilities are. Search scope
- Add Central Package Management more info
- Dependency management is a core feature of NuGet. Managing dependencies for a single project can be easy. Managing dependencies for multi-project solutions can prove to be difficult as they start to scale in size and complexity. In situations where you manage common dependencies for many different projects, you can leverage NuGet's central package management (CPM) features to do all of this from the ease of a single location.
- Add a file
Directory.Packages.propsto the src and test folders. This allows us to manage nuget package versions for all projects in a central location. I separated src and tests because tests have many dependencies and can cause confusion. Search scope info
Implementation
Part 1 Directory.Build.props
- Use MSbuild to:
- Manage all common properties across all projects
- These properties can be overridden by the project if it wishes to do so
Part 2 Directory.Build.targets (changes only happen in Release configuration)
- Use MSbuild to:
- Copy/Link
AWS.Lambda.Powertools.Common*.cs files to the destination project - Remove depdendency of Common project by removing
<ProjectReference Remove="..\AWS.Lambda.Powertools.Common\AWS.Lambda.Powertools.Common.csproj" /> - Add PackageReference
<PackageReference Include="AspectInjector" />
- Copy/Link
- This transformation only happens in Release configuration
Once in Release configuration or when running dotnet build -c Release the Common folder is added to the project
Part 3 Central Package Management
Starting with NuGet 6.2, you can centrally manage your dependencies in your projects with the addition of a Directory.Packages.props file and an MSBuild property.
This means that the versions of the referenced packages will be defined in the central Directory.Packages.props file
File contents:
In the csproj files of the projects the referenced packages will not have a version
If needed individual projects can override the version
Part 4 Nuget package contents
The resulting Release package will have no AWS.Lambda.Powertools.Common reference and will include AspectInjector nuget package. This will make the utility completely independent from AWS.Lambda.Powertools.Common Nuget package at runtime
Old:
New:
Removed AWS.Lambda.Powertools.Common project reference from test projects.
This reference now comes from Directory.Build.props. This file was added to test folder.
Contents:
Changes
🌟New features and non-breaking changes
🔧 Maintenance
- chore: Disable dependabot.yml (#475) by @hjgraca
- chore: Update version release 1.7.0 (#464) by @hjgraca
- chore(deps): bump gitpython from 3.1.30 to 3.1.35 (#451) by @dependabot
- chore: update changelog with latest changes (#437) by @hjgraca
- chore: bump examples NuGet versions (#435) by @amirkaws