ADR-171: Implement LayoutCompilerService as Native AOT Lambda#198
ADR-171: Implement LayoutCompilerService as Native AOT Lambda#198jodavis-claude wants to merge 14 commits into
Conversation
…ne place that can be updated.
… stdout, to minimize log agent noise
Directory.Exists() returns false when .git is a file (git worktree layout). Path.Exists() accepts both files and directories, so it correctly finds the repo root in worktree checkouts.
StubLayoutValidationClient was checking CssDefinitions == "INVALID", which was set by the now-replaced StubLayoutCompilerClient. With HttpLayoutCompilerClient, the signal is embedded in the element cssId: any cssId starting with "INVALID_" causes the real LayoutCompilerService to emit ".INVALID_<id>" in CssDefinitions, which the stub then detects. Update the E2E test to use cssId "INVALID_up-btn" to exercise the failure path end-to-end.
|
Code review findings posted for ADR-171. |
|
Code Review ADR-171 Two blocking issues and one nit found. BLOCKING 1 — Missing Properties/launchSettings.json for LayoutCompilerService _doc_BackendDevelopment.md requires: all Lambda projects must include a launch profile for the Lambda Test Tool. The ADR-171 exit criterion is Lambda Test Tool launch profile present. Every ECS Fargate service has a Properties/launchSettings.json; this Lambda service has none. Add a Properties/launchSettings.json with a Lambda Test Tool launch profile. BLOCKING 2 — _doc_BackendDevelopment.md is stale after ADR-171 Line 28 still says: Compile via ILayoutCompilerClient (stub: StubLayoutCompilerClient). ADR-171 replaced that stub with HttpLayoutCompilerClient backed by the real Lambda. Update step 3 to reference the real client. Also remove the StubLayoutCompilerClient bullet from the Stub implementations section since that stub no longer exists. NIT — StubLayoutValidationClient._forceInvalid is dead code forceInvalid is assigned from IConfiguration in the constructor but never read. It became unused when the stub was updated to detect the .INVALID prefix in CssDefinitions rather than a config flag. Remove the field and the IConfiguration constructor injection. |
_doc_BackendDevelopment.md requires all Lambda projects to have a launch profile for the Lambda Test Tool. This file was missing from the initial ADR-171 implementation.
…erClient references Pipeline step 3 now reflects HttpLayoutCompilerClient (the real HTTP client added by ADR-171). Remove StubLayoutCompilerClient from the Stub implementations list; it is no longer used.
…LayoutValidationClient _forceInvalid was assigned from IConfiguration but never read after the stub was updated to detect .INVALID_ in CssDefinitions. Remove the field and the IConfiguration constructor injection.
Test Results459 tests 450 ✅ 3m 25s ⏱️ For more details on these failures, see this check. Results for commit c452ce5. ♻️ This comment has been updated with latest results. |
|
Sign-off Review — ADR-171 Prior issues — all resolved:
New issue in post-review modified file (Priority 5 — Documentation):
The Validation:ForceInvalid=true config key was removed along with forceInvalid when StubLayoutValidationClient was updated. The failure path is now triggered by giving a layout element a cssId starting with INVALID (the real LayoutCompilerService emits .INVALID_ verbatim in CssDefinitions, which the stub detects). Suggested replacement:
Note: GitHub prevents submitting a formal review on your own PR. This comment records the sign-off findings in lieu of a formal review submission. |
…evelopment.md The config key was removed when StubLayoutValidationClient was updated to detect .INVALID_ in CssDefinitions. Update the stub description to document the current failure-path mechanism: give a layout element a cssId starting with INVALID_.
|
Sign-off Review #2 — ADR-171 Prior sign-off issue — resolved:
No new issues found in All exit criteria met. No Priority 1–5 issues remain. APPROVED. Note: GitHub prevents submitting a formal review on your own PR. This comment records the sign-off in lieu of a formal review submission. |
|
@copilot There are ApiTests failing during the build-and-test job, but ApiTests are supposed to be filtered out during that job. Can you investigate why they attempted to run during the latest PR run? |
Investigated on run 26241501345 (commit c452ce5). In |
Summary
AdaptiveRemote.Backend.LayoutCompilerServiceas a .NET 10 Native AOT Lambda functionPOST /compile(RawLayout → CompiledLayout) andPOST /compile/preview(elements → PreviewLayout) endpointsStubLayoutCompilerClientinLayoutProcessingServicewithHttpLayoutCompilerClientbacked by the real LambdaServiceFixture(Path.Existsinstead ofDirectory.Exists)What changed
New:
AdaptiveRemote.Backend.LayoutCompilerServiceAddAWSLambdaHostingLayoutCompilerservice: pure synchronous compilation — strips grid/CSS authoring properties, generatesCssDefinitionsfromRawLayoutElementDtogrid positions andAdditionalCss, produces preview HTML/CSSLayoutContractsJsonContext; no reflection-based JSONMessageLogger.cs(sharedAdaptiveRemote.Backend.Common)IsDevelopment(); health endpoint atGET /healthlocalstack-init/02-deploy-lambda.shprovisions the function in LocalStack on startupUpdated:
AdaptiveRemote.Backend.LayoutProcessingServiceHttpLayoutCompilerClientreplacesStubLayoutCompilerClient— calls the real Lambda over HTTPStubLayoutValidationClientupdated: detects the invalid path via.INVALID_prefix inCssDefinitions(emitted by the real compiler) rather than the hardcoded"INVALID"string from the old stubcssId: "INVALID_up-btn"to trigger the validation failure pathDesign notes
LayoutCompilerServiceis stateless and has no external dependencies (no LocalStack, no DynamoDB, no SQS), so it does not include a LocalStack startup health check — consistent with the Lambda pattern in_doc_BackendDevelopment.mdINVALID_prefix convention for exercising the validation failure path in E2E tests is documented inStubLayoutValidationClientWork item
ADR-171: https://jodasoft.atlassian.net/browse/ADR-171