Chore/parity upgrade - #2414
Open
agbishop wants to merge 250 commits into
Open
Conversation
Six issues from the PITR investigation and the parity survey that preceded it: make docs missing from CI so badges and README drift, stale PARITY.md frontmatter on three shipped services, seven services with no SDK-driven integration tests at all, the grading policy question for guardduty and wafv2, the PITR defects themselves, and a nav test that should assert a backend exists for every advertised dashboard route. Also closes gopherstack-1gfi, whose concrete finding was resolved by 87dee6d; its surviving hardening recommendation carries forward. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
First batch of the dependency upgrade: `go get -u=patch ./...` across all 464 modules, then `go mod tidy`. 43 direct modules moved, all patch-level — roughly 40 aws-sdk-go-v2 service clients (s3 v1.106.0 to v1.106.4, iam v1.56.0 to v1.56.2, lambda v1.100.0 to v1.100.2, and similar bumps for kms, ssm, sqs, sns, secretsmanager, ecr, ecs, eks, dynamodb, route53resolver, redshiftdata, codedeploy, codepipeline, amplify, appsync and iot), the AWS internal support packages (eventstream, config, credentials, internal/v4a, feature/ec2/imds, and the checksum, presigned-url, s3shared and accept-encoding internals), plus gopsutil, moby/moby/client, modernc.org/libc, golang.org/x/exp and genproto. No source changes were needed anywhere — `go build ./...` and `go vet ./...` are both silent. The AWS core is a non-event: aws-sdk-go-v2 v1.43.3 and smithy-go v1.27.6 were already at their latest releases, and the feature/ and internal/ packages had already been carried forward by the patch sweep, so requesting them at @latest changed nothing. Since no new SDK surface appeared, the coverage check is unmoved: zero forward failures across all 159 services, and the reverse phantom check still reports exactly the three known services (iotdataplane's 3 admin-only extensions, rds' GetPerformanceInsightsMetrics, s3's 3 presigned pseudo-ops). 158 direct modules remain behind — the aws-sdk-go-v2 service minors and the non-AWS majors, which are the next batches and are where actual parity fallout is expected. Gates: 66612 tests pass uncached, golangci-lint 0 issues, govulncheck finds nothing our code calls. One pre-existing advisory remains (GO-2026-5932, unmaintained golang.org/x/crypto/openpgp, no fix available) in a required-but-uncalled module. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ling we lack
Roughly 166 packages were behind. Shipped in gated stages:
The AWS SDK: 157 @aws-sdk/client-* packages plus credential-providers,
3.1094.0 to 3.1102.0. This also carried the undici override from 7.28.0
to 7.29.0, which clears two audit findings (one high, one moderate --
response-desync and cache-poisoning advisories) that npm audit already
flagged on this branch.
Svelte, Kit and Vite moved together, since runes and the vite plugin API
are coupled and a partial bump mismatches: svelte 5.56.7 to 5.56.8,
@sveltejs/kit 2.70.1 to 2.70.2, vite 8.1.5 to 8.2.0.
Tooling minors: oxlint 1.75.0 to 1.77.0, oxfmt 0.60.0 to 0.62.0,
svelte-check 4.7.3 to 4.7.4. No new lint or type findings.
jsdom took its major, 29.1.1 to 30.0.1, staged on its own because it is
the test-environment package the deferred goto-mock timing depends on.
url-state.test.ts was verified explicitly on top of the full suite; the
deferred-write mock in vitest.setup.ts is untouched and still behaves.
Tailwind needed no work at all -- it, Vitest, adapter-static and
@testing-library/* were already at their latest versions.
Two upgrades are deliberately not here, reverted rather than forced:
TypeScript 7 is blocked upstream. svelte-check 4.7.4, already the latest,
refuses to run under it: "TypeScript 7 support currently requires both
TypeScript 7 and TypeScript 6 installed... requires using the --tsgo or
--tsgo-experimental-api flag". Taking it would mean a dual-install npm
alias plus an experimental flag. Pinned back to 6.0.3.
@bufbuild/protobuf 1 to 2 and @connectrpc/connect{,-web} 1 to 2 generate
ui/src/lib/api/gopherstack/dashboard/v1/*.ts through buf, driven by
proto/buf.gen.yaml with plugins pinned at bufbuild/es v1.10.0 and
connectrpc/es v1.6.1. That config lives outside ui/, the buf and protoc
CLIs are not available here, and v2 changes the generated code from
class-based to schema-based -- hand-patching generated files is not a
substitute for regenerating them.
Gates: check 19839 files 0 errors 0 warnings, lint clean, fmt clean,
1911 tests pass across 170 files, build succeeds.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…erations
Batch 3 of the dependency upgrade. 156 of the 169
aws-sdk-go-v2/service/* modules moved; 136 were patch-only. The 20
minor bumps are the interesting ones: ec2 v1.317 to v1.319.1, glue
v1.149 to v1.152.0, sagemaker v1.261 to v1.263.2, quicksight v1.121 to
v1.123.1, iam v1.56.2 to v1.58.1, rds v1.123 to v1.124.1, cloudwatchlogs
v1.80 to v1.81.1, dynamodb v1.62.3 to v1.63.1, wafv2 v1.76 to v1.77.3,
and eleven others.
Nothing failed to compile and no source changed -- go build and go vet
are both silent.
What the bump did do is exactly what an SDK bump is supposed to do here:
make new AWS surface visible. TestSDKCompleteness now reports 31
operations we do not implement, across six services:
ec2 13 Application Status Check family, Transit Gateway
policy table entries
quicksight 8 TopicV2 family
kafka 5 Channels family
glue 3 data-quality ruleset evaluation, catalog export config
directconnect 1 ListVirtualInterfaceRoutes
dynamodb 1 SearchVectors
All 31 are additive new feature families, not renames. The reverse
phantom check confirms this: it found zero new entries, still reporting
only the three known exceptions (iotdataplane's admin extensions, rds'
GetPerformanceInsightsMetrics, s3's presigned pseudo-ops). There is no
operation we advertise under a name the SDK has since changed.
The two cleanup categories this batch was meant to sweep were both
empty. No notImplemented manifest entry has gone stale, and no route
needed re-pointing at a renamed operation.
Implementing the 31 operations is deliberately not in this commit -- they
need real backend state and wire shapes verified against the bumped SDK,
which is its own scoped work rather than something to bury in a
dependency bump.
Gates: go build and go vet clean, golangci-lint 0 issues. The unit suite
is red only on the six TestSDKCompleteness failures documented above.
One unrelated pre-existing flake surfaced under full parallel load
(services/eks TestAsyncLifecycle_Nodegroup, "status = CREATING, want
ACTIVE"); it passes in isolation and no eks module or source was touched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
31 new operations across six services, the two UI upgrades deferred for missing tooling, and the eks nodegroup flake. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…r services Four of the six services that TestSDKCompleteness started failing after the service-module bump. ec2 (13 ops) and quicksight (8) follow separately. kafka gains the whole MSK Channels family -- CreateChannel, DeleteChannel, DescribeChannel, ListChannels, UpdateChannel -- backed by real state. A channel created by CreateChannel is findable by Describe and List, mutable by Update, removed by Delete, and survives a snapshot/restore round trip. MSK is REST-JSON, so each route was matched against the SDK's serializers for method and URI path rather than guessed, and DescribeChannel's response was field-diffed against deserializeDocumentChannelInfo including every nested type. ListChannels returns the distinct, smaller ChannelInfo shape the SDK expects, not the full record. Tag operations now recognise channel ARNs, since CreateChannel accepts tags. glue gains BatchGetDataQualityRulesetEvaluationRun, which reads the existing dataQualityEvalRuns table and splits found from missing the way BatchGetCrawlers already does, plus Get and PutDataCatalogExportConfiguration. Neither export-configuration input carries a CatalogId, so it is modelled as one backend-global singleton following the existing identity-centre config pattern, and it really stores the encryption configuration and timestamps. Three of these operations could not be implemented with real data, and took validation plus an honest empty response rather than invented values. dynamodb SearchVectors: gopherstack models no vector index anywhere -- neither CreateTable nor UpdateTable has any code path that attaches one. The operation validates all four required fields, does a real table lookup, and then returns ResourceNotFoundException for the index using the same message format Query and Scan already use for a missing GSI. That is honest rather than evasive: no vector index can exist in this backend, so "not found" is always true. directconnect ListVirtualInterfaceRoutes: BGPPeer records track configuration only, never a live BGP session's route table. The operation validates the virtual interface exists and returns an empty route list. glue's export configuration reports Status settling synchronously to match ExportSetting, since there is no real S3 Tables pipeline to move through ENABLING or DISABLING, and leaves S3TableBucketArn empty because no input field anywhere in the API supplies it. All three are recorded in their services' PARITY.md gaps, along with kafka's: channel lifecycle operations complete immediately with no CREATING window, CreateChannel does not restrict creation to MSK Express clusters since gopherstack has no cluster-type distinction, and it does not verify TopicArn references resolve. Gates: TestSDKCompleteness passes for all four, go build and go vet clean, golangci-lint 0 issues, all package tests pass under -race. Refs gopherstack-dtay Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ady owns The SDK bump to v1.123.1 exposed an eight-operation TopicV2 family: Create, Delete, Describe, List, Search, Update, plus DescribeTopicPermissions and UpdateTopicPermissions. The design question was whether V2 is a separate resource or a second schema over the existing one. Three pieces of SDK evidence say the latter. CreateTopicInput and CreateTopicV2Input carry an identical "unique per Region per account" doc comment for TopicId with no separate V2 namespace, and both return ResourceExistsException on collision. types.TopicUserExperienceVersion, which exists only on the V1 shape, has the value NEW_READER_EXPERIENCE -- the V1 side already models "this topic uses the V2 schema". And the V2 permissions outputs are byte-identical to V1's with no version discriminator, because permissions belong to the topic, not to a schema version. So all eight operations read and write the same b.topics collection rather than a parallel store. Only CreateTopicV2 and UpdateTopicV2 needed new backend methods, since they genuinely accept different parameters -- no UserExperienceVersion or Permissions, plus CustomInstructions and DataSetRelations, with full-replace update semantics. Describe, Delete, List and Search call the existing V1 backend methods, and both permission operations route to the existing V1 handlers. A dedicated test proves the sharing: a topic created through V1 is visible to DescribeTopicV2, a topic created through V2 is visible to V1's DescribeTopic with UserExperienceVersion NEW_READER_EXPERIENCE, DeleteTopicV2 removes a V1-created topic, and an ID collision across the two families conflicts. Routes were read off the serializers rather than inferred, which caught one trap: SearchTopicsV2 carries MaxResults and NextToken in the JSON body, while ListTopicsV2 takes them as query parameters. One gap is recorded honestly. The two schemas are not losslessly convertible -- V1 has ConfigOptions and rich DatasetMetadata, V2 has DataSetRelations and CustomInstructions -- so each family's exclusive fields are stored separately rather than one clobbering the other, and are not projected into the other family's Describe. There is no SDK evidence for how real AWS projects one into the other, so inventing a mapping would be fabrication. Implementing this also surfaced two pre-existing V1 bugs, left unfixed here and filed separately rather than silently carried forward into V2: V1 SearchTopics reads MaxResults and NextToken from query parameters when the real SDK puts them in the body, and V1 DeleteTopic's response omits the Arn the real DeleteTopicOutput carries. Gates: TestSDKCompleteness passes, go build and go vet clean, golangci-lint 0 issues, package tests pass under -race. Refs gopherstack-dtay Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…licy table entries The last 13 of the 31 operations the SDK bump to v1.319.1 exposed. Transit Gateway policy table entries -- Create, Delete and Modify -- build on the policy table model that already existed, adding a real entry store keyed by policy table and rule number, mirroring the metering policy entry pattern. Create validates that TargetRouteTableId refers to a route table that actually exists, Modify implements AWS's "unspecified fields retain their current value" semantics, and DeleteTransitGatewayPolicyTable now cascades to entries as well as associations. This also fixed a claim that the bump falsified. GetTransitGatewayPolicyTableEntries carried a comment stating "Real AWS exposes no API to create policy table entries directly" and returned an always-empty list. That was true when written and is not true now, so it returns real stored entries. Application Status Checks -- ten operations covering create, delete, modify, associate, disassociate, three describes, and suppression enable/disable. The check is a health-check definition associable with instances or tags and individually suppressible per instance. Real documented defaults are applied on create (path /, interval 60, timeout 6, failure threshold 2, success threshold 5, status code matcher 200, initialization grace period 300, aggregation included) and the real 50-check-per-account quota is enforced. Suppression flips genuinely persisted state that the describes then reflect, rather than being accepted and dropped. DescribeApplicationStatus is the one operation that cannot be honest and complete at once, because nothing here executes real HTTP health checks. It never returns ok, impaired or initializing. It returns only the three ApplicationStatusEnum values that are fully derivable from tracked state: suppressed, not-applicable when no included-aggregation check applies, and insufficient-data when a check is associated but has never run -- each matching that value's documented AWS meaning. A test asserts the fabricated values can never be produced. Reading both deserializers rather than assuming symmetry caught a trap: SuccessfulAssociationResponseObject.AssociationType uses INSTANCE_ID and EC2TAG, while ApplicationStatusCheckAssociationObject.AssociationType uses instance-id and tag. Same concept, two vocabularies, in one family. Gaps recorded in PARITY.md: HealthCheckPaths is not modelled, and AvailabilityZoneId, StatusSince and per-check Details are left empty rather than invented. With this, TestSDKCompleteness passes across all 159 services -- the full forward check is clean and the reverse phantom check still reports only the three known exceptions. Gates: go build and go vet clean, golangci-lint 0 issues, package tests pass under -race. Refs gopherstack-dtay Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The reverse check finds operations gopherstack advertises that the AWS SDK does not have. It has been reporting them through tb.Logf as a staged rollout. The rollout is over: across all 159 services only three still report phantoms, and all three are legitimate. So the check now asserts instead of logging, backed by a documented allowlist holding exactly seven names -- s3's PostObject, PresignedGetObject and PresignedPutObject, which are presigned-URL pseudo-operations rather than SDK methods; iotdataplane's ListConnections, ListThingsWithShadows and RegisterConnection, which are gopherstack admin-only extensions served on /_admin paths; and rds' GetPerformanceInsightsMetrics, deliberately kept because deleting it would remove real capability with no replacement. Each entry carries its justification inline. The allowlist is a package-level map keyed by the SDK client's concrete type rather than a new CheckCompleteness parameter, because the function already derives everything from that client by reflection and a new parameter would have meant touching all 160 call sites. Nothing was added to export_test.go. Verified the assertion can actually fail, since a strict check that never bites is worse than the tb.Logf it replaces: injecting a fake operation into a service's supported-operations list produces "Should be empty, but was [...]", and removing it returns to green. check_test.go's TestCheckCompleteness_ReportsPhantomOpNonFatally asserted the old non-fatal behaviour, so it is renamed and now asserts the spy recorded a failure. rds returns to A. Both reasons for its downgrade are resolved: DescribeCustomDBEngineVersions was removed from the wire surface by the same pass that recorded the downgrade, and GetPerformanceInsightsMetrics is no longer an undisclosed gap now that it is an explicit allowlist entry. Its two pre-existing gaps did not block an A grade before and do not now. The old rationale is kept below as history rather than deleted. The terraform-test target's timeout goes from 10m to 45m; the suite takes about 23 minutes, so the gate was failing spuriously. Closes gopherstack-vhw2, closes gopherstack-zv7f Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…cs they feed cmd/gendocs builds the root README table, every per-service README and the public badges from PARITY.md frontmatter, so stale frontmatter is not a cosmetic problem -- it makes the project misreport itself. networkmanager's manifest still opened "PRE-IMPLEMENTATION AUDIT, NOT YET BUILT -- services/networkmanager/ does not exist yet". That was true when written and was falsified by 87dee6d, which shipped the service: 95 operations, 45 Go files, 9662 non-test lines, 17 cli.go references. Its families were all marked gap and it carried no ops rows at all. Every operation row was derived by reading code, not assumed. For networkmanager the route builders across handler.go and the eleven handler_*.go files were diffed against the SDK's own 95-operation list and matched exactly. 81 operations are ok; 14 are partial, each with a specific reason -- cross-service EC2 and DirectConnect ARNs accepted without a live backend reference to validate against, StartRouteAnalysis returning a deterministic NOT_CONNECTED with no transit gateway graph walk, the core network change set and change events endpoints returning an empty diff because there is no policy-JSON diff engine, routing information and network routes empty because there is no BGP engine, and network telemetry reporting UP only. mgn had the same shape of problem -- body prose describing a finished implementation while families and ops stayed stuck on the pre-implementation gap state. Its 95 operations are now recorded, 83 ok and 12 partial, and the prose claims were re-verified against the code rather than trusted: the S3 wiring really is in cli.go, StartImport really does read S3, and the mapper-segment and network-migration result endpoints really do always return empty. directconnect only needed its leftover "Zero operations implemented" line removed; its 64-operation table was already accurate. No overall grade changed. All three depend on the integration-test question in gopherstack-r9yz, which is what actually gates their grades, and networkmanager deliberately keeps its gap marker until that is settled rather than being quietly promoted here. The regenerated docs move the badges from 5681 to 6076 operations and from 154 to 161 services, and networkmanager, mgn and directconnect get per-service READMEs for the first time -- they had never been generated, because a manifest with zero ops rows produces nothing. Closes gopherstack-3ajx Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… check caught
Flipping the reverse phantom check to a hard assertion immediately caught
something the tb.Logf version had been quietly logging: bedrock advertises
GetAgentMemory and DeleteAgentMemory, which are not methods on the
bedrock-agent control-plane client the check reflects over.
They are real AWS operations, on the bedrock-agent-runtime data-plane
client this repo does not vendor as its own service. Both are genuinely
implemented and wire-shape-routed under
/agents/{id}/agentversions/{v}/memories/..., and the reason was already
documented at services/bedrock/handler_agents_dispatch.go:137 -- the
check simply cannot see the runtime client. So they belong in the
allowlist, alongside the rds entry that exists for the same reason.
Worth recording why this was missed the first time. The verification
sweep ran `go test -run TestSDKCompleteness ./services/...`, and 157 of
the 158 sdkcheck call sites use exactly that name. bedrock's is
TestAgentsHandler_SDKCompleteness, so the -run filter skipped it, and the
sweep reported clean while a service was broken. The full `make test` run
is what caught it. A name-filtered sweep is only as complete as the naming
convention it assumes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Important Review skippedToo many files! This PR contains 2097 files, which is 1997 over the limit of 100. To get a review, reduce the PR to 100 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. Usage-priced reviews support at most 300 files. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (5)
📒 Files selected for processing (2097)
You can disable this status message by setting the |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
Collaborator
Author
📊 Code Coverage Report
Tip This project maintains a minimum coverage threshold of 85%. Maintain or improve coverage on new code to ensure long-term stability. Last updated: Sun, 09 Aug 2026 02:21:45 GMT |
…nistic Comments on this branch were running ~12.5% of added lines, with quicksight/topics_v2.go and pkgs/sdkcheck/check.go around 50%. Per the rule now in CLAUDE.md, comments should be short and pointed or absent -- Go reads fine on its own, and walls of prose cost more context than they explain. Removed: file-level essays restating the package summary, section banners, multi-paragraph quotes of AWS docs, narrated history of what past passes changed, and restatements of the following line. Kept, compressed to a line or two: the reason a decision was made, the landmines, and verified external facts with their source. Specifically surviving are the dynamodbSnapshotVersion warning, every phantomAllowlist justification, the wire-shape traps (SearchTopicsV2 carrying pagination in the body while ListTopicsV2 uses query params; the two different AssociationType vocabularies in one EC2 family), and the no-fabrication reasoning behind DescribeApplicationStatus, SearchVectors and ListVirtualInterfaceRoutes. Godoc on exported identifiers stays. Net: 425 comment lines deleted, no behaviour changed. Separately, services/eks is the first package in this repo to use testing/synctest. Its five sleeps now run inside a bubble against a fake clock, so the async cluster, nodegroup, addon and fargate transitions are deterministic instead of racing a 50ms wall-clock margin -- the shape that produced "status = CREATING, want ACTIVE" under parallel load. The package also got faster, 1.64s to 1.21s, since the real sleeping is gone. Honest note on that: the agent doing the conversion could not actually reproduce the flake, having tried -count=20, -cpu=1, eight concurrent runs, and GOMAXPROCS=1 under sixteen CPU-stress processes. So the fix is justified by the fragile construction and by determinism, not by an observed failure this session. One subtlety worth recording. The sleeps were kept inside the bubbles rather than replaced with synctest.Wait(). Wait() blocks until existing goroutines are durably blocked; it does not advance the fake clock to fire a timer that is not yet due, which is what these tests are actually waiting on. Sleeping past the deadline is the idiom the Go docs use for this. The margin is also deliberately kept strictly greater than the production delay -- an exactly-equal sleep ties at the same fake instant with no defined ordering, which would trade a load-dependent race for a deterministic one. Inside a bubble that margin costs nothing. Refs gopherstack-5biv Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
mulint detects mutex self-deadlocks -- recursive locks, missing unlocks,
deferred re-locks. It was initially wired in as a golangci-lint module
plugin, which had to be undone for two reasons.
First, it broke CI. Enabling a module plugin in .golangci.yml makes stock
golangci-lint hard-fail with 'plugin(mulint): plugin "mulint" not found',
and the lint workflow installs a stock binary. Making that work needs a
custom-gcl build in CI, which is workflow machinery we do not want.
Second, and more decisive, the plugin would have guarded almost nothing.
mulint only follows a mutex wrapper when the wrapper type is declared in
the same package. Probing all three shapes: wrapper in the same package
held by value is detected, same package held by pointer is detected,
wrapper in a different package held by pointer is not detected at all.
lockmetrics.RWMutex lives in pkgs/lockmetrics and is used across package
boundaries in 190 of roughly 260 mutex declarations, spanning all 192
service files. So the repo-wide "0 findings" was largely a false clean
rather than a clean codebase.
It is still worth having for the ~70 direct sync.Mutex and sync.RWMutex
declarations, and for new code that reaches for sync directly, so it now
runs in the lint target as a vet tool:
go vet -vettool=$(go tool -n mulint-vet) ./...
Pinned in go.mod's tool block at v1.1.0 alongside govulncheck and
gotestsum, so there is no separate install step and no workflow change.
Both behaviours were demonstrated before landing this. A recursive
sync.Mutex lock in the same package is reported; the identical bug written
against lockmetrics.RWMutex is silently missed. AGENTS.md states that
limit plainly rather than implying coverage the tool does not have.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
# Conflicts: # .beads/issues.jsonl # services/dynamodb/persistence.go
… iot and s3control Two independent sweeps. testing/synctest now covers transfer, sqs, grafana, lambda and pkgs/worker, following the pattern established in services/eks. 50 sleeps moved into bubbles, where the clock is fake and a wait costs no wall-clock time. The sleeps that remain inside those bubbles are not a leftover: sleeping past a timer deadline is the correct idiom, since synctest.Wait only waits for existing goroutines to block and does not advance the clock to fire a timer that is not yet due. Each is kept strictly longer than the delay it waits on, because an exactly-equal sleep ties at the same fake instant with no defined ordering. Three sleeps in services/lambda are deliberately left alone and documented in place: handler_runtime_test.go drives a real loopback HTTP server and a Docker-mock runtime API, and real network I/O is not durably blocking, so a bubble would hang rather than help. That is the boundary for the rest of this sweep too -- test/integration, test/e2e and test/terraform cannot use synctest at all and want require.Eventually instead. All five packages pass -race -count=10. Separately, iot and s3control were the two worst services for oversized comment blocks (59 and 54 blocks of 8+ lines). iot drops 382 comment lines, s3control 304. Removed: narrated history including bd issue numbers, section banners, verbatim AWS doc quotes, and prose restating what the code says. Kept and compressed: AWS wire-shape facts with their SDK source, the no-fabrication notes, landmines, and godoc. The blocks that survive are dense factual content already down to 8-14 lines. Verified comments-only: no identifier, control-flow, or behaviour change leaked into that half of the diff. Refs gopherstack-5biv Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ng guardduty and wafv2 to A A- was rejected as a ceiling for these two, and the schema had no way to express what was actually true about them: not "incomplete", but "correct, and this data cannot exist here". The inconsistency is measurable. 80 of the 151 services already graded A carry non-empty gaps, so gaps have never blocked an A in this repo. guardduty and wafv2 were held lower precisely because their limitation was structural and honestly documented -- a stricter standard than 80 of their peers were held to. So _PARITY_TEMPLATE.md gains a structural_gaps key. A structural gap is one no implementation could satisfy in an emulator because the underlying data source cannot exist: no real traffic, no ML or AI engine, no billing or settlement system, no physical hardware. Those do not block an A, but must be recorded separately rather than buried in gaps. Explicitly not an escape hatch -- anything that could be built with more effort stays in gaps. That line was drawn per gap, not per service, and most entries did not move. guardduty keeps in gaps its missing per-feature member-account enrollment tracking and its lack of a state model for individually scanned files: both are absent state models that could be built. wafv2 keeps its undocumented ApplicationIntegrationURL scheme and its vendor-onboarding-only ManagedRuleSet fields for the same reason. One entry moved in each service -- guardduty's Investigation status, which needs account-level finding correlation and Bedrock-backed analysis, and wafv2's four revenue-reporting operations, which need real HTTP traffic, bot detection and a settlement system. Both already validate requests to AWS's own rules and return honestly empty responses. Nothing was fabricated to reach this grade, and nothing about their behaviour changed. gendocs parses the new key and renders it as its own labelled section in each service README plus a count in the root table, so an A grade always shows what cannot be emulated instead of hiding it. Adding the parser case pushed parseFrontmatter over cyclop's branch cap, so scalar-key handling was extracted rather than suppressed with a nolint. Badges move from 151 A / 3 A- / 4 B to 153 A / 1 A- / 4 B. The six services still below A -- mgn, directconnect, grafana, outposts, resiliencehub and networkmanager -- are blocked on integration-test coverage, not grading policy. See gopherstack-r9yz. Closes gopherstack-4h6q Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Tests that do real Docker or loopback network I/O cannot run inside a synctest bubble, because real I/O is not durably blocking and the bubble would hang rather than advance. Those were left sleeping when the synctest sweep went through. They are now polled instead. 45 sleeps across test/integration, test/e2e, test/terraform and services/lambda become require.Eventually against the condition each was actually waiting for -- a resource reaching ACTIVE, a message arriving, a log line appearing -- with generous timeouts and short ticks, so a slow or loaded machine still passes where a fixed sleep would not. Two remain, both because the wait is not a condition: services/lambda/handler_runtime_test.go sleeps for tt.responseDelay, where the delay itself is the thing under test -- it simulates a slow runtime response, so polling it away would delete the test's subject. test/integration/autopurge_test.go waits 22 seconds for a TTL window to elapse before creating fresh resources. Nothing exposes "has N seconds passed", so a poll would be a sleep wearing a disguise. The integration suite was run for real against Docker (91.9s, passing), not skipped. Also continues the comment sweep through ec2, mgn, s3, ecs and dynamodb. Repo-wide, blocks of 8+ consecutive comment lines are down from 2139 to 1947. Verified comments-only: no behaviour, identifier or control-flow change in that half of the diff. Refs gopherstack-5biv Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…to A test/integration/directconnect_test.go drives the real aws-sdk-go-v2 client against a running container: connection/LAG lifecycle, private/public/transit VIFs with BGP peers, DirectConnectGateway associations/proposals against real EC2 VpnGateway/TransitGateway resources (proving the existing EC2 cross-service validation end-to-end), and tagging including the global dx-gateway ARN. Re-judged all 12 PARITY.md gaps: moved 7 genuinely unbuildable items (physical cross-connect, real LOA-CFA content, AWS's proprietary location/ router catalogs, real legal agreements, MACsec hardware, real BGP sessions, partner billing, Cloud WAN) to structural_gaps. Left 2 gaps open (CloudFormation resource types belong to services/cloudformation; secretsmanager- backed MACsec keys deferred to avoid stacking cli.go edits onto a concurrent agent's in-flight work). bd: gopherstack-6y3m Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…na and networkmanager to A
Three services claimed the same REST prefix and only MatchPriority decided
who won.
services/bedrockagent's RouteMatcher checked the SigV4 service scope and
then fell through to an unguarded path-prefix match on /tags/, /agents,
/flows, /prompts and /resourcepolicy, so it answered any other service's
request on those paths. services/cleanrooms had the same unguarded /tags/
match. grafana and networkmanager also serve /tags/.
A previous pass had "fixed" networkmanager by raising its MatchPriority to
88 so it outranked bedrockagent. That masked the defect system-wide rather
than fixing it, and when the escalation was reverted -- correctly -- it
un-masked cleanrooms, which registers before grafana at the same priority
and was returning 404 for everyone else's tag ARNs. Re-escalating would not
have helped: cleanrooms beat grafana regardless of networkmanager.
The fix is httputils.MatchesTaggedResourceARN, which disambiguates on the
ARN already present in the path -- arn:{partition}:{service}: -- rather than
on priority or on the signing scope. The ARN names its true owner
unambiguously, so every service serving /tags/ can now match only its own
requests: cleanrooms, grafana, mgn, networkmanager, outposts and
resiliencehub all use it. bedrockagent keeps its prefix fallback but no
longer takes it when the signing scope names a different service.
managedblockchain already guarded its own match, and the remaining bare
prefix checks in omics and bedrock are internal dispatch that runs after
matching, so they cannot steal anything.
test/integration/tag_routing_test.go tags resources across several services
in ONE binary run, which is the only way this class is visible -- each
service passes its own suite in isolation while silently answering another's
traffic.
Riding along, two services reach A.
grafana gains an SDK-driven integration suite and real cross-service
validation: WorkspaceRoleArn against IAM, VPC subnets and security groups
against EC2, organizational units against Organizations, and SSO grants
against ssoadmin and identitystore. Its FAILED and DEGRADED workspace
states are now reachable through chaos injection instead of every
transition resolving to ACTIVE. ListVersions moves to structural_gaps: the
supported-version catalog is operational data with no SDK encoding, so no
implementation can derive it.
networkmanager gains its own integration suite and replaces two
placeholders with real behaviour: StartRouteAnalysis now walks EC2's
modelled transit gateway route tables with longest-prefix match and returns
genuine CONNECTED, BLACKHOLE, INACTIVE or ROUTE_NOT_FOUND verdicts, and
GetCoreNetworkChangeSet diffs the stored policy JSON for real. Telemetry
and BGP routes move to structural_gaps -- no BGP session or device
telemetry exists anywhere in this repo to derive them from. Its stale
"gap" grade, left from when the manifest was a pre-implementation spec,
becomes A.
Gates: 66687 tests pass, golangci-lint 0 issues, govulncheck clean, and the
grafana, networkmanager and tag-routing integration suites pass against
Docker.
Closes gopherstack-sokq, gopherstack-4spv, gopherstack-xhi2
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
… A- to A mgn had 95 operations and roughly 12k lines of implementation behind only 960 lines of test, and no SDK-driven integration coverage at all. It now has a suite driving the real aws-sdk-go-v2 client through source servers, replication and launch templates, jobs, applications and waves. That suite immediately earned its place by catching a bug no unit test could see: UpdateSourceServer parsed FqdnForActionFramework and UserProvidedID off the wire and then never applied them, and silently wiped ConnectorAction on every update. Four more gaps closed with real behaviour. StartImport's CSV schema was invented. It now uses AWS's documented mgn:server:* parameters -- an invented schema is precisely the fabrication this campaign exists to remove, and it was worse than an empty response because it looked plausible. ModifiedCount was hardcoded to zero and now counts real modifications, keyed on mgn:server:user-provided-id the way AWS's own documentation describes. StartTest and StartCutover minted a synthetic instance ID that referred to nothing. They now launch a genuine EC2 instance through services/ec2 via a new cross_service.go, following the pattern grafana established, and the integration test confirms the instance with a real DescribeInstances call. A migration service whose launched instances do not exist is the kind of shape-correct-but-hollow behaviour that makes an emulator untrustworthy. ListManagedAccounts previously returned only the caller's own account and now resolves real Organizations member accounts. Moved to structural_gaps with individual justification: the absence of CreateSourceServer and CreateVcenterClient, NetworkMigrationExecutionID creation, and network-migration analysis, codegen and deployment content. Left in gaps as a deliberate scope call: the mgn:app:, mgn:wave: and mgn:launch:* CSV columns, which are a materially larger feature rather than an unbuildable one. Gates: build and vet clean, go test -race passes, golangci-lint 0 issues, and the Docker-backed integration suite passes. Closes gopherstack-xd34 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ldable gaps, held at B
outposts had 43 operations, 10 open gaps and no SDK-driven integration
coverage. It now has a table-driven suite exercising outposts, sites,
orders, catalog items, capacity tasks and tagging through the real
aws-sdk-go-v2 client.
The grade stays at B, deliberately.
The gap that matters most -- wiring RunInstances into the Outposts
capacity ledger, so capacity depletes as instances launch the way real
Outposts does -- cannot be built from this side. services/ec2 has no
Outpost-placement fields at all, so there is nothing for outposts to read;
even the read-only cross-service pattern grafana established has no source
to read from. That needs an ec2-side change first, filed as
gopherstack-9ij1. Raising the grade with that unbuilt would be exactly the
kind of claim this campaign exists to stop making.
Three gaps were reclassified as structural with individual justification,
covering physical hardware state and real AWS catalog inventory, and one
stale CloudFormation entry was dropped as a non-gap.
The suite also surfaced a second instance of the routing bug class fixed
earlier this branch: services/iotdataplane's matcher claims
/connections/{id} at a higher priority than outposts and was shadowing
real GetConnection calls. Fixed on the outposts side with a SigV4-gated
matcher rather than by raising MatchPriority -- priority escalation is
what produced the original bug. The iotdataplane-side fix is filed as
gopherstack-vpoh, and the two affected cases are skipped with that issue
cited rather than quietly dropped.
Gates: build and vet clean, golangci-lint 0 issues, the full -race suite
passes, and the Docker-backed integration suite passes with the one
documented skip. The pre-existing tag-routing isolation test was rerun to
confirm the matcher change broke nothing.
Refs gopherstack-b9mg
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
cmd/gendocs output had drifted from the manifests. The badge now reports 157 A and 2 B, matching live frontmatter, after mgn moved from A- to A. Also refreshes the directconnect and mgn service READMEs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…cement resiliencehub goes from B to A. It gains an SDK-driven integration suite over apps, app versions, resiliency policies, assessments, recommendations and tagging, plus real cross-service resolution: ResolveAppVersionResources now resolves an app version against the actual EC2, RDS and DynamoDB backends instead of echoing whatever it was handed, using the pattern grafana established and mgn reused. Its remaining gaps are genuinely structural and now say so. Bedrock-backed assessments and AWS's proprietary resiliency scoring have no derivable data source in an emulator -- the deliberate scorePlaceholder of 0.0 was already an honest admission of that, and it stays honest rather than being filled with an invented number. services/ec2 gains Outpost placement: RunInstances accepts Placement with an OutpostArn, instances carry it, and it surfaces wherever the SDK says it does. services/outposts consumes that, so launching onto an Outpost now depletes real capacity and terminating returns it, verified end to end through the real SDK client rather than asserted. outposts stays at B, and that is the right call. The capacity coupling was its last cross-service blocker, but two pre-existing buildable gaps remain: Order and CapacityTask lifecycles jump straight to their terminal state instead of passing through IN_PROGRESS, DELIVERED and WAITING_FOR_EVACUATION, and buildOrderingRequirements evaluates 2 of the 17 real check types. Both are buildable, so under the template's own rule they belong in gaps and gaps block A. Two stale historical notes in that manifest are marked superseded. Gates: build and vet clean, -race tests pass across all three packages, golangci-lint 0 issues, and the Docker-backed integration suites pass. Closes gopherstack-lxs2, gopherstack-9ij1 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| // ec2.Instance at all -- matches real RunInstances failing atomically. | ||
| var instanceIDs []string | ||
| if outpostArn != "" { | ||
| instanceIDs = make([]string, count) |
Foundation for showing resources from every region at once. The dashboard fans out concurrent per-region calls from the client; there is no backend wildcard region and no response annotation, because the UI already knows which region it called. ALL_REGIONS is a "__all__" sentinel rather than a real region name, since regions here can be arbitrary and any real-looking value could collide. currentRegion() resolves the sentinel down to DEFAULT_REGION, so the 149 pages not yet converted keep working exactly as before instead of receiving a region string they cannot use. Fresh users now default to All. Two region lists, kept deliberately separate. The full catalog comes from EC2 DescribeRegions and feeds the picker's autocomplete. The much smaller set of regions that actually hold data comes from /dashboard/api/system/regions and is what the fan-out iterates -- issuing a request per region in the full catalog on every page load would be unacceptable. A 404 from that endpoint is treated as empty and falls back to the default region, so the UI does not depend on the endpoint landing first. The hardcoded eleven-region array in +layout.svelte is gone; it was a second source of truth and had already drifted. multiRegionList takes a closure that performs the send itself rather than a client factory plus a command. That is not a style preference: passing a command through an extra layer of structural typing loses the SDK's per-call generic inference and widens every response to the client's broadest union. It also builds a new client per region, never reusing one, because @aws-sdk/core freezes a client's SigV4 signing region on its first request -- a reused client would sign the second region's request as if it were still the first. In single-region mode the helper collapses to exactly one call, and a rejection propagates to the caller's own try/catch with the original error intact rather than being swallowed into the errors list, which is only correct once more than one region is in flight. RegionChip renders on every resource including global services, since it is a filter affordance rather than a claim about storage, and global resources must not vanish when a region is selected. WriteRegionHint shows "using <region>" beside create actions only while All is selected. dax and dynamodb are converted as pilots. The remaining pages follow once this pattern has been reviewed, because it gets copied a further 190 times. Gates: svelte-check 0 errors across 19847 files, oxlint clean, formatting clean, 1911 tests across 174 files, production build succeeds. Refs gopherstack-eez5, gopherstack-iisp Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…ns hold data Two region sources the dashboard's Region All mode needs. They are deliberately different lists and must not be conflated. DescribeRegions was returning stubRegions, a hardcoded ten entries with a comment admitting they were stubs. Real AWS has far more, so a wire-accurate operation was returning inaccurate data -- the same class of dishonesty this campaign has been closing elsewhere, and worth fixing on its own merits rather than as UI scaffolding. It now returns 34 regions read from the pinned aws-sdk-go-v2/service/ec2 v1.319.1 module's own endpoints data for the "aws" partition, so it tracks the SDK rather than a hand-maintained list. cn, us-gov and iso regions are excluded as separate partitions a commercial account does not see. The wire shape is untouched; only the data changed. GetSpotPlacementScores, the only other caller, follows the rename. Separately, the UI must fan out only to regions that actually hold something -- a request per region on every page load would be unacceptable. pkgs/service/regions.go tracks that with one middleware rather than a new interface method: ChaosRegions already exists on the service interface with 141 implementations that all just return the default region, so extending that path would have meant 161 edits for something the request path gives for free. The middleware hangs off registry.Use, the same chokepoint chaos.Middleware uses, and reads the region through the extraction that already happens there. The set is guarded by a lockmetrics.RWMutex with an RLock-first check so the common case, a region already known, never takes the write lock. Results are exposed at GET /dashboard/api/system/regions beside the existing system/state and system/health. The tracker persists its own recorded set through the existing snapshot manager. That detail matters: the first attempt seeded the set by scanning other services' persisted snapshots for region-code substrings, which produced false positives -- services/account bakes a static eight-region catalog into its default state as reference data, and a substring scan cannot tell that apart from a real resource, so a completely fresh server advertised eight regions with nothing in them. Persisting the tracker directly removes the guesswork. Seeding on restore is the requirement that makes this correct rather than merely working. Without it, regions holding restored data are unknown until something happens to touch them, and their resources are silently invisible in All mode -- a wrong answer that only appears after a restart with existing data. Verified end to end: a fresh server reports only us-east-1, writes to us-east-1, ap-south-1 and eu-west-2 make all three appear, and after a full restart all three are still reported before any new request, with the underlying resources intact. Gates: build and vet clean, -race tests pass, golangci-lint 0 issues across the whole repo, and DescribeRegions returns 34 regions live. Closes gopherstack-nh6m Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
StartWorkflowRun wrote a bookkeeping record and started nothing. It now fires the workflow's entry triggers, so a run has actions to count, and those job runs and crawls carry the run that started them. Statistics are computed from live run state rather than tracked separately, which is how the API describes them. The errored and waiting counters are documented as job runs specifically, unlike the other six, so crawls stay out of those two. No wire field links a run to its workflow run -- not on job runs, crawls or crawler history -- so the link is internal and stripped from every response that returns a job run. TriggerName is real and was simply never populated. Left undone: predicate-gated triggers still do not fire, since nothing watches for completions, so only an entry trigger's own actions are counted. The per-node run lists on a workflow's graph remain unmodelled. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
AutoRemove and the explicit Terminate both removed the container, so Docker had a removal in flight by the time Terminate asked for its own, and nearly every shard logged a failure at teardown. Nothing ever broke, but a real container fault produced the same message, so the noise hid it. AutoRemove is the side to drop. It only removes a container Docker has already stopped, so it does nothing when a shard dies without tearing down -- the reaper covers that case, and it is enabled here. Terminate does more besides: it detaches the reaper hook, removes volumes, runs the teardown hooks, and drops the image this container builds from source. The other four container helpers in this suite already do it this way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Path forms of the item batcher's two limits, the reader's item cap and the map's concurrency were not modelled at all, so the decoder discarded them and the settings had no effect. Nothing warned, because nothing knew the fields existed -- unlike the fallbacks fixed earlier, these never reached code that could notice. They resolve against the map state's own input, the way the tolerated failure settings already do, and the Path form wins when both are given. A resolved value that is not a number now fails the execution rather than being ignored, matching the existing behaviour for tolerated failure counts. Task's timeout and heartbeat have the same asymmetry, but resolving them touches every task state and belongs in its own change. The tests run real executions. The bug was that the struct had no field to assert on, so a parser test could not have caught it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…mp the embedded UI The static linux build and the ordinary build both wrote bin/gopherstack. Running the latter while integration tests were in flight replaced the binary the scratch image needs with one it cannot execute, and the failure arrived as a missing container, which looks like Docker's fault. The linux target has its own path now, the test image copies that, and the harness checks the file is a static ELF before starting a container -- so a wrong binary fails saying so. CI referenced the old path in six places and follows the rename. Nothing it gates on changed. Separately, dashboard/static/spa is gitignored and embedded, so a bare go build embeds whatever stale bundle happens to be on disk. That already cost a false bug report, where icons appeared broken that had been fixed in source. The UI build now writes a stamp alongside the bundle and the server logs it at startup, so a repro can say which build it is actually running. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It builds its own static linux binary and feeds the same test image, so it has to write the path that image now copies. Missed when the rename landed, which left the image looking for a file this suite was not producing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…tempt Both Path forms were unmodelled and dropped by the decoder. They resolve from the state's input like the map settings before them, the Path form wins over its literal sibling, and a non-numeric value fails the execution. Modelling them exposed an older bug in the same code. The timeout context was built once, outside the retry loop, so every attempt shared a single deadline -- a retry after a timeout re-entered an already-expired context and could not run. The specification counts the timeout from each attempt's own start event, and AWS's own retry-on-timeout example only makes sense that way. Each attempt now gets its own deadline from the resolved value. A test asserted the broken behaviour: it expected a timed-out task never to retry, which was true only because the second attempt died instantly on the expired context. It expects four attempts now. Batches were also emitted as a bare array. The real shape wraps them, with the batcher's fixed input alongside when set. The timeout tests run on a virtual clock, so they assert exact elapsed time rather than waiting -- including that three attempts take three times one attempt's timeout. Left alone: every path in this executor resolves against the input after Parameters is applied, where the real service resolves before. That is long-standing and affects all of them, not just these. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Seven handlers formatted times with a literal +00:00 in the layout. Go does not read that as an offset, so it was copied out verbatim and every response claimed UTC whatever zone the time carried -- a time in +05:00 was printed with its own wall clock and a UTC suffix, which is neither. The service really does always emit +00:00 rather than Z, so the fix is to convert to UTC first and use the offset token that still renders +00:00 at zero. Reaching for RFC3339 would have produced Z and changed the shape. Persistence is unaffected: snapshots marshal the time values themselves, not these response strings. The audit claimed this format was correct, and iotwireless's still described the position payloads as JSON-wrapped after they became raw bodies. Both corrected. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…rms the input Every Path field read the state's input after Parameters had rewritten it, so a path naming a field Parameters does not carry through resolved to nothing or to whatever happened to sit at that position. The specification applies InputPath first, and Parameters consumes that result -- reference paths read the same value Parameters does, not its output. AWS documents a task whose Parameters replaces the whole payload while its timeout path still reads a field only the original input has. The pre-Parameters input was already computed and simply not passed on. It now reaches the path resolutions for items, concurrency, tolerated failures, the batcher and reader limits, and the task timeout and heartbeat. The work payload is untouched: invocation, per-item selection, catch and result handling all still use the transformed input. No test combined Parameters with a path field, which is why this held. Six now do, each hiding the real value behind a decoy that only the transformed input carries. Credentials are not modelled here at all, so the role ARN path the issue mentioned has nothing to fix. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A routing rule's ARN carries an account id, unlike the domain name ARN it nests under. This one was built with an empty account segment, so it never matched what a real client would construct. The domain name ARN itself is correct as it stands. It is deliberately identical to the v1 spelling: v2 signs under the same apigateway name, has no ARN namespace of its own, and a domain name is a resource shared between the two API surfaces rather than owned by either. So there is no wire difference to introduce there -- only a routing hazard if v2 is ever registered for tagging, which has to be resolved by asking each backend whether it owns an id rather than by matching the ARN. An existing test asserted the empty account even while setting a real one in its own context. Also raised the coverage run's unit timeout, which was half the budget of the identical uninstrumented run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…nfigurations Two more of the nine missing serverless families, picked for being the most self-contained: resource policies depend on nothing, and snapshot copy configurations only on namespaces. Delete is not uniform across this service. Deleting a snapshot copy configuration returns the deleted object, and the response marks it required, where deleting a resource policy or a custom domain association returns nothing at all. Assuming one shape for all three would have been wrong in both directions. The envelope convention does hold for both of these, so the custom domain family's flat responses remain the exception rather than a pattern. No one-configuration-per-namespace limit is modelled, because the service documents none -- unlike its non-serverless counterpart, which does. The remaining five are recorded. Recovery points, table restore status and the two restore operations are mutually dependent and should be taken together; endpoint access and the managed workgroup listing are separate and smaller. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…eir restore operations The entangled group, taken together because a table restore from a recovery point needs a real recovery point to name. There is no operation that creates a recovery point. The API documents them as made automatically every thirty minutes and kept for a day, so one is generated when a workgroup is created rather than exposed as an endpoint that does not exist. Seeding more for tests goes through an internal helper, not the wire. The per-field timestamp split this service is prone to shows up inside this one group: a recovery point's creation time is ISO 8601 while a table restore's request time is epoch seconds. Restoring a namespace from a snapshot is deliberately still absent -- it depends on no recovery point, so it was never part of this group -- along with converting a recovery point to a snapshot. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Timeouts were accepted, stored and echoed back on describe, and never enforced -- the timed-out status existed and nothing ever set it. That also left terminate as the only way to trigger a child policy, where the real service invokes it on exactly two events, terminate and timing out. An execution past its limit now closes with a timed-out event carrying the child policy and timeout type the API requires, and the cascade runs through the same code terminate already used. The sweep is synchronous, taking the instant to evaluate as an argument, and runs at the top of the operations that read or change execution state. No goroutine, and no waiting in tests. Only the execution-level limit is enforced. Decision task and the four activity task timeouts are still accepted and ignored, and the audit now says so per operation -- a timeout that fires for some kinds and not others is worse than one that never fires, since the difference is invisible. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Create and modify endpoint accept nineteen engine-specific settings blocks and modelled none of them, so a client configuring an S3 target or a Kafka broker got a success and an endpoint with none of that configuration. Modelling them properly means about three hundred fields across nineteen heterogeneous structs, which is more than one change can do faithfully, and a subset would be worse than the gap: a caller seeing some settings kept would reasonably assume the rest were. So the request is refused, naming the block that is not supported, the way unsupported inputs are already refused elsewhere in this repo. That does mean refusing something the real service accepts. It is the honest of the two failures -- a caller now learns immediately, instead of discovering later that the endpoint was never configured. Nothing is stored, so describe has nothing new to omit, and the password handling from the earlier pass is untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Endpoint access, managed workgroup listing, restore from snapshot and converting a recovery point to a snapshot. All nine families the audit recorded as absent now exist. Endpoint access omits its VPC endpoint object entirely, following what this package's classic Redshift already decided: the network interfaces underneath need availability zones, addresses and subnets that nothing here can produce, and inventing identifiers with no interface behind them would be worse than leaving the object out. The VPC filter is refused for the same reason. What is real -- address, ARN, status, port, subnets, security groups -- is served. Managed workgroups always list empty, and that is the honest answer rather than a stub: the source ARN is pattern-locked to a Glue catalog, so these exist only where Lake Formation federation provisions them, and this backend has no such integration for anything to come from. Restoring a namespace from a snapshot follows the recovery-point restore already here. Managing the admin password is honoured only in the direction that has meaning; the other reinstates credentials as they were when the snapshot was taken, which is not reconstructible, so it is left alone rather than faked. Deleting an endpoint access echoes the deleted object, unlike deleting a resource policy or a custom domain association. That is the third distinct delete shape in this service. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A pipeline definition given as an S3 location was rejected outright, which was honest but useless. It is now fetched from the S3 backend, wired the way the other cross-service integrations are. Rejection remains only where the object genuinely cannot be read -- no backend, missing bucket or key, or a failed read -- so a caller is told rather than handed a fabricated pipeline. The wiring test drives initializeServices, so deleting the call site fails it; the helper compiling proves nothing. Restricted instance groups stay unmodelled for a third pass, and the audit now records the whole verified type tree so the next attempt does not re-derive it. Two findings from that reading: the instance storage config really is a discriminated union, unlike the orchestrator beside it, which only reads like one; and there is a second top-level field nobody had named, carrying its own shared environment config. Eight further types, across two fields rather than one -- comparable to the whole four-field pass that preceded it, and not something to shave down. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
… a stack Neither an app nor a resiliency policy could be created through a stack. Both follow the supplemental-resource pattern the KMS and Secrets Manager types already use, calling the real backend and failing loudly rather than returning a stub id. Resilience Hub already imports this package, so the reverse import would cycle. The dependency is declared here as an interface the other side satisfies structurally, which is the same technique its own cross-service resolution already uses. The template body and resource mappings are required by the resource type and are not fields of the create call at all -- they are separate operations chained after it. Tags on these two are a plain map rather than the array of pairs most resources take, and Ref yields the ARN, which is what the physical id is set to. Drift status via GetAtt still falls back to the physical id. Reading it needs a backend, and the attribute resolver is deliberately pure, so that would change every resource type's signature. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
No description provided.