Merge upstream master to resolve mergeable_state=dirty on PR #2530 - #3
Merged
Conversation
…s#2517) * Add durable execution conformance test harness (.NET, step suite) Wire the .NET Durable Execution SDK into the language-neutral aws-durable-execution-conformance-tests runner. The runner deploys a SAM template, invokes each mapped Lambda, and validates the durable execution result and event history against language-agnostic requirement specs. - Conformance/ under the durable integration tests: per-suite template_step.yaml mapping functions to requirement ids via TestingMetadata.TestDescription, plus one executable handler project per requirement referencing the in-repo SDK directly. - Full step suite implemented (1-1 .. 1-20); retry-across-invocation tests use a DynamoDB AttemptsTable. Verified 20/20 PASSED against real AWS. - scripts/: build_examples.sh (dotnet publish -> publish/<Fn>/), discover_suites.py (CI matrix), inject_execution_role.py (CI role). - conformance-tests.yml workflow: per-suite matrix, OIDC creds, pip-install runner, inject role, JUnit upload. - Exclude Conformance/** from the parent test project's compile glob so the standalone handler types don't collide. * Port remaining 8 conformance suites (.NET) — all 9 suites green Add handlers + SAM templates for wait, child, callback, invoke, parallel, map, wait_for_callback, and wait_for_condition, completing every durable execution conformance suite for .NET. Handlers ported from the internal DurableExecutionsSDKTestingFramework reference, with ProjectReferences retargeted to the in-repo SDK. Suite coverage (verified end-to-end against real AWS, us-east-1): - step 20, wait 5, child 18, callback 19, invoke 16, wait_for_condition 13, wait_for_callback 15, parallel 22, map 20. - 122 passed, 0 failed. 6 requirements declared NotImplemented (custom-serdes gaps: 3-14, 5-16, 8-15, 9-14, 9-19, 9-20) — the .NET SDK has no per-operation serdes slot; all payloads use the one registered ILambdaSerializer. Notes: - Retry-across-invocation tests (child 3-7, 3-12) use the AttemptsTable DynamoDB table, like the step suite. - invoke deploys two callee target functions (InvokeEchoTarget, InvokeFailTarget) wired via AWSSDK.Lambda; the tenancy test reuses the echo binary under a second logical id (InvokeEchoTargetTenant) produced by build_examples.sh aliasing. - child 3-11/3-17 log through the durable context logger (records carry durableExecutionArn, which the runner filters on); 3-11 disables replay-aware filtering so the ReplayChildren re-execution is also observed. * Default conformance region to us-west-2 to match CI accounts The aws-dotnet-ci test-runner accounts are us-west-2, and durable execution is available there, so align the conformance workflow's default region (still overridable via the CONFORMANCE_AWS_REGION repo variable). * Gate conformance CI on missing coverage (--fail-on failed+uncovered) The runner + its test-requirements are pinned to @main, so new upstream requirements are pulled automatically. With the default --fail-on (failed), a new requirement with no .NET handler reports UNCOVERED and the run stays green — silently missing coverage. Switch to failed+uncovered so a new requirement turns CI red, prompting a handler (or a NotImplemented declaration). Declared gaps report NOT_IMPLEMENTED and never block. Also fix stale secret/variable names in the README CI section (CONFORMANCE_* not TEST_ROLE_ARN/AWS_REGION) and document the coverage gate + what to do when it fires. * Fix conformance CI: mark build_examples.sh executable, pin action SHAs - Set the git executable bit (100755) on build_examples.sh so the 'Publish conformance handlers' step no longer fails with 'Permission denied' (exit 126) when invoked as ./scripts/build_examples.sh. - Pin all GitHub Actions in conformance-tests.yml to full commit SHAs (checkout, setup-dotnet, setup-python, setup-sam, upload-artifact), resolving the Semgrep mutable-action-tag findings.
Co-authored-by: aws-sdk-dotnet-automation <github-aws-sdk-dotnet-automation@amazon.com>
…#2494) Rewrite the LambdaTestTool-v2 README to be usage-first and fix several copy-paste-breaking inaccuracies: - Add a top-of-page Quick Start (install -> run -> invoke -> result) and a Prerequisites section (.NET 8+, PATH for global tools, verify step). - Fix the API Gateway route Endpoint example to use the base URL (http://localhost:5050) instead of appending the function name. - Make emulator-mode examples consistently HttpV2 to match the sample handler (avoids HTTP 502) and normalize Get/HttpV2 casing. - Correct and complete the command-line options table; document the info command, SQS and DynamoDB Streams event sources, the web UI workflow, built-in sample events, saved requests, and theming. - Add Troubleshooting and Known Limitations sections; remove the duplicate H1 and stale version note; reframe the Aspire pointer. Add runnable sample projects under samples/ (AddFunctionTopLevel, AddFunctionClassLibrary, SQSProcessor, ToUpperFunction), each with its own README and committed launch profile. Add a .gitignore exception so the samples' launchSettings.json files are tracked. Document CLI launch path for class-library functions Verified end-to-end that a class-library Lambda function can run from the command line (not just an IDE). The Executable launch profile relies on the IDE expanding $(Configuration) and resolving workingDirectory, which plain 'dotnet run --launch-profile' does not do. - Add CopyLocalLockFileAssemblies to the AddFunctionClassLibrary sample so its NuGet dependencies are copied to the build output, making the function self-contained for a command-line 'dotnet exec' launch. - Restructure README Option 2 to lead with the command-line 'dotnet exec' steps and keep the IDE launch profile as a secondary option, noting the dotnet-run-vs-IDE caveat. - Rewrite the sample README with both command-line and IDE launch paths. Address PR feedback: bump samples to net10, fix API GW mode and config-storage-path docs
The trim/AOT PropertyGroup (IsTrimmable, EnableTrimAnalyzer) was gated on '$(TargetFramework)' == 'net8.0'. Once net10.0 was added to DefaultPackageTargets, the net10.0 assembly shipped unmarked, so a net10 NativeAOT consumer resolving that asset gets the assembly-level IL3053 rollup from Amazon.Lambda.Serialization.SystemTextJson. Drop the condition so all target frameworks are marked trimmable. Applied the same fix to APIGatewayEvents, SQSEvents, SNSEvents and SimpleEmailEvents, which had the identical net8.0-only gating.
…ws#2542) * onboard: single-trunk Execute Release workflow (master, 3 pipelines) Add .github/workflows/execute-release.yml (manual dispatch) that bumps version + changelog via AutoVer, commits to master, tags + creates a GitHub Release, then starts the aws-lambda-dotnet, aws-lambda-dotnet-powershell, and aws-lambda-testtool pipelines (freeze-aware, HOLD-aware). Remove create-release-pr.yml and sync-master-dev.yml (replaced). * security: harden execute-release.yml per zizmor - Route AutoVer release tag/name through env vars in the GitHub release step (avoids template-injection via ${{ steps.* }} in a run block). - Suppress artipacked on Checkout: persist-credentials must stay true so the deploy-key git config survives for the version/changelog push.
…ent model (aws#2544) * feat(CloudWatchEvents): add Step Functions Execution Status Change event model Adds StepFunctionsExecutionStatusChangeEvent (and its detail types) to Amazon.Lambda.CloudWatchEvents, modeling the EventBridge-delivered 'Step Functions Execution Status Change' event. Includes unit tests (started and failed cases across all serializers) and sample event payloads. Closes aws#2126 * fix: type redriveDate as epoch-millis long, not string The AWS docs annotate redriveDate as a string, but the actual EventBridge event delivers it as Unix epoch milliseconds (a JSON number), consistent with startDate/stopDate. Typing it as string would throw a JsonException on a real redriven execution event. Adds a regression test with a numeric redriveDate.
The dev integration branch is no longer used; the repo now follows a single-trunk flow on master (see Execute Release workflow, f5bbe7d). Update all workflows that still referenced dev: - auto-update-Dockerfiles.yml: checkout ref and PR destination -> master - update-Dockerfiles.yml: checkout ref and PR destination -> master - aws-ci.yml: remove dev from PR trigger branches - conformance-tests.yml: PR trigger branches [dev, master] -> [master] - semgrep-analysis.yml: push trigger branches [dev, master] -> [master]
…emplate (aws#2546) The DurableExecutionSerializerContextDiagnosticsTests and the non-fatal DurableExecutionDiagnosticsTests cases emit only warnings/info, so the source generator does not short-circuit and proceeds to the CloudFormation sync, which reads and writes a generated serverless.template on disk. That file is shared with the other generator-running test classes (SourceGeneratorTests, DurableExecutionE2ETests), which xUnit runs in parallel. Those two were already protected by [Collection(TestServerlessAppCollection.Name)] (DisableParallelization), but the two durable diagnostic classes were not, so their template read could collide mid-write and surface as AWSLambda0001 (JSON parse error). Enroll both durable diagnostic classes in the same serialization collection so no two generator-running test classes touch the template concurrently.
* chore: point dependabot at the default branch (remove target-branch: dev) * chore: add dependabot cooldown (satisfies semgrep dependabot-missing-cooldown)
* Honor IncludeCategory in the JSON log format In text format the ILogger category is written on every line when LambdaLoggerOptions.IncludeCategory is true (the default), but the JSON branch of LambdaILogger.Log never emitted the category, so migrating a function from text to JSON logging silently lost it with no way to opt back in (aws#2469). When IncludeCategory is set, prepend a {Category} placeholder to the message template and supply the category value, so it surfaces as a queryable property in the JSON record instead of being dropped. Text format is unchanged, and JSON output is unchanged when IncludeCategory is false. Fixes aws#2469 * chore: add change file for logging category fix * fix: prepend category as plain text, not a template placeholder Copilot's review on this PR caught a real issue: prepending a {Category} placeholder to honor IncludeCategory in JSON mode makes the formatter's positional-argument detection treat the whole template as named, which can shift how a caller's own {0}/{1} placeholders line up with their values. Prepend the category as literal text instead, same as the text format already does. Updated the two category tests and added one covering a positional template to confirm it stays untouched. All 17 tests pass locally on net8.0 and net10.0. * chore: restore the original line endings in LambdaILogger.cs The first commit normalized the whole file to CRLF where upstream has mixed endings, so the diff read 74 changed lines when only 11 lines actually change. Content is unchanged: git diff -w against the previous commit is empty.
…404) (aws#2492) * Fix Test Tool v2 Blazor UI non-interactive on .NET 10 (static assets 404) On .NET 9+ the Blazor framework files (_framework/blazor.web.js) and the scoped-CSS bundle are served through the endpoint-routing MapStaticAssets API backed by the *.staticwebassets.endpoints.json manifest, not the classic static-files middleware. The tool only registered a wwwroot-only UseStaticFiles provider, so on net10 those assets returned 404, window.Blazor was never defined, no interactive server circuit was established, and the whole UI rendered statically (buttons/@onclick/@Bind non-functional). Add a NET9_0_OR_GREATER-guarded app.MapStaticAssets() so net9+ serves the framework + scoped assets via the endpoints manifest while net8.0 keeps its existing path. Also disable the build-manifest dev-time runtime-patching handler (ReloadStaticAssetsAtRuntime=false), which otherwise probes those assets through the physical wwwroot provider and threw FileNotFoundException (HTTP 500) for _framework/* under dotnet run/build. Serve net10 Blazor framework assets with real bytes (fix 0-byte 200 responses) The previous fix made _framework/blazor.web.js return HTTP 200 but with an empty (0-byte) body, so window.Blazor was still never defined and the UI stayed non-interactive. Two root causes, both fixed here: 1. MapStaticAssets serves asset bytes from IWebHostEnvironment.WebRootFileProvider. Under dotnet run the framework files live in the NuGet cache and are mapped in via *.staticwebassets.runtime.json, but ASP.NET Core only composes that manifest into the web root automatically in the Development environment. The tool runs as Production by default, so the web root was a bare wwwroot provider and the invoker caught FileNotFoundException and returned an empty 200. Fixed by calling builder.WebHost.UseStaticWebAssets(), which composes the manifest regardless of environment (and is a harmless no-op for the installed tool, where the framework files are published directly into wwwroot). 2. As an installed global tool the process launches from an arbitrary working directory, and the default content root (hence WebRootFileProvider = contentRoot/wwwroot) followed the cwd, so MapStaticAssets looked in a nonexistent wwwroot and returned empty 200s for every asset. Fixed by pinning ContentRootPath to AppContext.BaseDirectory. Replaces the earlier ReloadStaticAssetsAtRuntime=false workaround, which only suppressed the dev hot-reload 500 but left MapStaticAssets serving 0 bytes. Verified on net10 with byte counts and a real browser (Playwright window.Blazor): - dotnet run: blazor.web.js=200575 bytes, styles.css=2024, bootstrap=232808; window.Blazor=true on / and /documentation. - installed global tool launched from a foreign cwd: same byte counts; window.Blazor=true on / and /documentation. net8 still builds and stays interactive (window.Blazor=true). Only MapStaticAssets when the manifest exists (fix net10 unit tests) TestToolProcess.Startup is invoked directly by unit tests (RuntimeApiTests, RunCommandTests) inside the xUnit test host. MapStaticAssets() throws InvalidOperationException when the *.staticwebassets.endpoints.json manifest is absent, and the manifest is named after the entry assembly — under the test host that's 'testhost', so the tool's manifest isn't present and every test that calls Startup failed on net10 (net8 was unaffected as it doesn't call MapStaticAssets). Guard the call so it only maps static assets when the expected manifest exists: the running tool has it (assets serve, UI is interactive); the test host does not (skipped, and those tests only exercise the Runtime API). Verified: the previously-failing net10 tests pass, and the real tool still serves _framework/blazor.web.js with real bytes. Fix RCL _content/** assets 404 on .NET 8 (dotnet run) The Blazor web UI's static-asset serving was only fully fixed for .NET 9+. On .NET 8, running from a build output (dotnet run / dotnet build) left Razor class library content — notably BlazorMonaco's _content/BlazorMonaco/** editor assets — returning 404, so the request/response code editor never initialized and selecting an example request could not populate the input. Root cause: those RCL assets are not physically under wwwroot in a build output; they are surfaced through the static-web-assets runtime manifest. UseStaticWebAssets() (which composes that manifest into the WebRootFileProvider) was guarded to net9+, and the classic UseStaticFiles middleware was pinned to an explicit bare-wwwroot provider that never reads the composed manifest. On net9+ MapStaticAssets reads the WebRootFileProvider so it worked there; net8 had no such reader. Fix: - Compose the static-web-assets manifest on all target frameworks (make UseStaticWebAssets() unconditional). - On .NET 8, add a second UseStaticFiles pass over the WebRootFileProvider so manifest-mapped _content/** assets resolve. For an installed global tool the WebRootFileProvider is the same wwwroot (assets published there directly), so it is a harmless second lookup. Verified across the full matrix — .NET 8/.NET 10 x Development/Production x dotnet-run/installed-tool (8/8 serve _framework, _content/BlazorMonaco, and app.css with non-zero bytes). * Simplify TestToolProcess static-asset comments and regroup per-TFM handling Address PR feedback on the three static-file registrations. No functional change: same UseStaticFiles/MapStaticAssets calls and guards, verified green across the full {net8,net10} x {Production,Development} x {dotnet run,installed} matrix. - Trim the verbose per-block comments (~54 -> ~28 lines) while keeping the facts. - Merge the separate #if !NET9 / #if NET9+ regions into one #if/#else placed right after the base UseStaticFiles, framing static assets as two layers: a manifest-independent base (classic wwwroot) plus per-TFM handling for the manifest-mapped framework/scoped-CSS/RCL _content assets.
…erge-conflicts # Conflicts: # Libraries/src/Amazon.Lambda.Logging.AspNetCore/LambdaILogger.cs Co-authored-by: Lanayx <3329606+Lanayx@users.noreply.github.com>
Copilot
AI
changed the title
Merge upstream aws/aws-lambda-dotnet master into Lanayx master (resolve PR #2530 conflicts)
Merge upstream master to resolve mergeable_state=dirty on PR #2530
Sep 8, 2026
Copilot created this pull request from a session on behalf of
Lanayx
September 8, 2026 17:59
View session
Lanayx
marked this pull request as ready for review
September 8, 2026 18:07
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
aws/aws-lambda-dotnet#2530(Lanayx:master→aws:master) reportedmergeable_state: dirty. The head branch had simply fallen behind base (ce85d89→180bc942), not a merge-commit structural problem.Changes
aws/aws-lambda-dotnet:master(180bc942) intoLanayx/aws-lambda-dotnet:master(08e8fd97), producing a two-parent merge commit.Libraries/src/Amazon.Lambda.Logging.AspNetCore/LambdaILogger.cs, where this branch's structured scope key/value JSON logging and upstream's newIncludeCategoryJSON prefix both modified the same code path in the JSON-format branch ofLog<TState>.Conflict resolution
Both features are additive and independent — scope keys/values are appended to the message template first, then the category prefix is applied on top:
This restores
mergeable_state: cleanagainst current upstreammasterwithout altering either feature's behavior.