Conversation
bakayolo
force-pushed
the
fix/snapshot-payload-size
branch
from
429a645 to
e96b271
Compare
…d limit The RetrieveFindings activity returned all findings as a single Temporal activity result, which exceeded the 4MB gRPC message limit for large inventories (12K+ Aurora clusters = ~10MB serialized). Instead of passing findings through Temporal payloads, CreateSnapshot now reads directly from the in-memory store. Findings stay within the worker process and never transit Temporal's gRPC layer. - Remove RetrieveFindings activity and its registration - CreateSnapshot accepts ResourceTypes and reads from store itself - Orchestrator passes successful resource types instead of findings - All detection workflows still run in parallel via child workflows Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
bakayolo
force-pushed
the
fix/snapshot-payload-size
branch
from
e96b271 to
a69cdaa
Compare
endoflife.date returns EOL and Support as either date strings or booleans. The ProductCycle struct typed them as string, causing JSON unmarshal errors for products like ElastiCache Redis where eol: false. Also, endoflife.date uses coarse cycles (e.g., '8.0', '7') while Wiz reports full versions (e.g., '8.0.35', '7.1.0'). Both the EOL provider and policy now use prefix matching to find the right cycle. - Change ProductCycle.EOL and .Support from string to any - Add anyToDateString helper to extract dates from any-typed fields - Add prefix-based version matching in GetVersionLifecycle - Add versionMatches to policy for cycle-to-version comparison - Fix EKS provider to handle EOL as any type Results: ElastiCache went from 0% to 94.1% compliance with real EOL data. Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
- Unblock EKS from ProductsWithNonStandardSchema — endoflife.date data works correctly (eol=end of standard support, extendedSupport=true EOL) - Fix aurora-postgresql mapping to amazon-aurora-postgresql (was wrong) - Remove aurora-mysql mapping (no endoflife.date product exists; needs AWS API) - Handle k8s- version prefix in policy version matching - EKS: 41.9% compliance (65 GREEN, 90 RED), 0 UNKNOWN - ElastiCache: 94.1% compliance Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
Resources past standard support but still in extended support were incorrectly classified as RED because: 1. convertCycle checked EOL date before extended support window 2. Policy treated IsDeprecated as RED even when IsExtendedSupport was set Now: extended support check runs first, and policy excludes extended support resources from RED status. EKS k8s 1.30/1.32 correctly show as YELLOW with 'in extended support (6x standard cost)' message. Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
Keep aurora-mysql in ProductMapping with a TODO referencing the pending endoflife.date PR #9534. Remove the now-empty ProductsWithNonStandardSchema blocklist and its guard code. All EOL data comes from endoflife.date. Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
- Fail if all detection workflows fail (no empty snapshots) - Fail on store read errors in CreateSnapshot (was silently skipping) - Remove unused SignalActWorkflowInput - Remove stale Stage 3 / non-standard schema / EKSEOLProvider comments - Add kubernetes to required engines test Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
bakayolo
force-pushed
the
fix/snapshot-payload-size
branch
from
164a1d8 to
6dc70cc
Compare
- Replace 'hybrid EOL' (AWS APIs + endoflife.date) with endoflife.date only - Add supported resources table with status, inventory source, and EOL source - Fix workflow start command (OrchestratorWorkflow, not VersionGuardOrchestratorWorkflow) - Remove AWS credentials from prerequisites - Document how to add new resource types (2 steps) Co-authored-by: Amp <amp@ampcode.com> Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c
bakayolo
force-pushed
the
fix/snapshot-payload-size
branch
from
6dc70cc to
4900fb5
Compare
Amp-Thread-ID: https://ampcode.com/threads/T-019d92b6-b80d-731a-8a83-64e6442ae52c Co-authored-by: Amp <amp@ampcode.com>
bakayolo
changed the title
Kiran01bm
approved these changes
Apr 15, 2026
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
2 participants
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.
Summary
Fixes the detection pipeline to produce real, usable compliance data for EKS and ElastiCache using only endoflife.date for EOL data — no AWS API credentials needed.
What changed
Temporal payload fix
RetrieveFindingsactivity that returned all findings through Temporal gRPC (12K+ findings = 10MB, exceeds 4MB limit)CreateSnapshotnow reads directly from the in-memory store — findings never transit TemporalEOL data from endoflife.date only
ProductCycle.EOLand.Supportchanged fromstringtoany(endoflife.date returns booleans or date strings)ProductsWithNonStandardSchema)aurora-postgresqlmapping toamazon-aurora-postgresqlaurora-mysqlmapping (pending endoflife.date#9534)ProductsWithNonStandardSchemablocklist and dead codeVersion matching
8.0matches resource version8.0.35k8s-prefix normalizationClassification
Validated with docker-compose (real Wiz data)
Single-pod assumption
The in-memory store is shared between detection and snapshot activities because everything runs on a single Temporal worker. This is intentional — we don't anticipate scaling this service to multiple pods.