resourcegroupstaggingapi

Resource Groups Tagging API

Parity grade: A · SDK aws-sdk-go-v2/service/resourcegroupstaggingapi@v1.35.4 · last audited 2026-08-07 (pending (uncommitted this pass -- see git log at merge time))

Coverage

Known gaps

• GetComplianceSummary always reports zero noncompliant resources. This is NOT simply 'no tag-policy engine exists' (services/organizations does model TAG_POLICY content, attachment, and effective-policy merging) -- the real blocker is architectural: real GetComplianceSummary is a management-account-only operation that aggregates noncompliant counts across every member account in an organization (verified against the AWS API reference, whose example response returns rows for three distinct account IDs), and gopherstack has no multi-account resource-store simulation anywhere to aggregate across. A single-account approximation would misrepresent the operation's actual (cross-account) contract, so was not built. Documented, not fabricated (bd: gopherstack-i710).
• CLOSED 2026-08-07 (gopherstack-3xfq): ListRequiredTags now parses a policy's report_required_tag_for element for real -- see the ListRequiredTags ops row above. NEEDS CENTRAL WIRING (cli.go, out of this service's scope): nothing currently calls resourcegroupstaggingapi.RegisterTagPolicyProvider. The wiring should look up the current account's effective TAG_POLICY via services/organizations' DescribeEffectivePolicy("TAG_POLICY", accountID) and register a closure returning (content, ok) from it -- mirroring how other cross-service registrations already happen in cli.go's wireResourceGroupsTagging for RegisterProvider/RegisterARNTagger. Until wired, ListRequiredTags continues to correctly return an empty list (no tag policy configured), not an error.
• cli.go's wireResourceGroupsTagging covers only ~91 of gopherstack's ~90 services (RegisterProvider/RegisterARNTagger/RegisterARNUntagger for cross-service resource discovery) -- a pre-existing gap, out of this service's scope, tracked separately (bd: gopherstack-3xne).
• ResourceTypeFilters validation uses a regex stricter than the real (unconstrained) schema, and ResourceARN has no enforced 1011-character max -- not investigated or fixed this pass (gopherstack-3xfq's stated scope also named these; ran out of time after the tag-policy engine and the SRP-6a work prioritized elsewhere this session).
• Cross-service tag wiring (cli.go wireResourceGroupsTagging) now covers 55 of the ~90 services with native TagResource support -- see cli.go's wireResourceGroupsTagging doc comment for the exact wired list. Latest sweep added accessanalyzer, dlm, ce, mediapackage, swf, fis, codeconnections, mediastore, mwaa, pipes (10 services, bringing the count from 45 to 55). Every new service fit the existing resourceTypeFromARN/constantResourceType dispatch without needing further generalization: accessanalyzer (analyzer/{name}), dlm (policy/{id}), mediastore (container/{name}), pipes (pipe/{name}), and mwaa (environment/{name}) tag exactly one resource kind each, so each uses a constant resource type; ce (costcategory/anomalymonitor/anomalysubscription), mediapackage (channels/origin_endpoints), fis (safety-lever/experiment-template/experiment), and codeconnections (connection/host/repository-link) mix several kinds in one flat ARN-keyed store, so each uses resourceTypeFromARN to derive the type per-ARN. Two needed a documented exception rather than a code change: swf's domain ARN has a literal leading slash before its resource segment ("arn:aws:swf:region:account:/domain/{name}", confirmed against swfARNRegex in services/swf/tags.go), which would make resourceTypeFromARN read an empty type from the leading separator, so it uses a constant resource type instead; mwaa's ARNs use the real AWS "airflow" service namespace rather than "mwaa" (confirmed against every arn.Build call in services/mwaa), which the wiring passes explicitly rather than the package's own name. Several other candidate services (macie2, managedblockchain, mediaconvert, datasync, codedeploy, inspector2, and more) have native TagResource support with what looks like the same flat-ARN shape this sweep wired, but were not pursued this pass -- each would need its own TaggedResources()-style accessor added to its backend (like the ten added this sweep) before it could be wired, and none of that accessor work was started or verified, so none of it is claimed done. s3control remains blocked as before (its taggable ARNs live under the "s3"/"s3-object-lambda" service namespaces rather than "s3control" itself, so the current arnServiceIs single-namespace dispatch doesn't fit it) (bd: gopherstack-3xne).
• This pass (gopherstack-3xne) wired the six services the prior sweep named but did not pursue: macie2, managedblockchain, mediaconvert, datasync, codedeploy, inspector2 -- bringing the count from 55 to 61. Each needed its own new TaggedResources() accessor (none had one): macie2 (allow-list/custom-data-identifier/findings-filter/classification-job, flat b.tags map), managedblockchain (accessors/members/nodes/networks via arnToResource type-switch on each resource's own Tags field -- invitations carry no Tags field and are never tagged), mediaconvert (jobTemplates/jobs/presets/queues, flat b.tags map), datasync (agent/location/task, flat b.tags map -- task executions build a nested ARN but isKnownResource never recognizes them so they can never be tagged), codedeploy (application/deploymentgroup, tags live on Application.Tags/DeploymentGroup.Tags via pkgs/tags.Tags, not a flat map), inspector2 (filter only in practice -- resourceExists gates tagging to filter ARNs or an ARN already seeded into b.tags, and only CreateFilter does that seeding). All six ARN shapes were confirmed against each service's own arn.Build call sites before wiring; none needed a namespace or nested-segment exception like the SWF/MWAA/DAX/Cognito traps found in earlier passes, except codedeploy's application/deploymentgroup ARNs use a colon (not slash) before the resource segment -- resourceTypeFromARN already handles both separators, so no change was needed there. s3control remains blocked as documented (bd: gopherstack-3xne).
• ResourceTypeFilters format validation (resourceTypeFilterRE, requiring lowercase 'service[:type]' shape) is stricter than the real API's AmazonResourceType schema, which declares pattern [\s\S]* (i.e. no server-side pattern constraint beyond max length 256). Predates this sweep; left unchanged because there is no confirmed evidence of real AWS's actual runtime rejection behavior for malformed resource-type filters (docs describe the convention but the schema doesn't enforce it), and changing validation behavior without positive confirmation risks trading one mismatch for another. Flagged for a future sweep with real-AWS or integration-test verification.
• This pass (gopherstack-3xne, fourth sweep) wired eight more: RAM, Rekognition, Translate, AppStream, MediaTailor, VPCLattice, CodePipeline, KinesisAnalyticsV2 -- bringing the count from 61 to 69. Each needed its own new TaggedResources() accessor (none had one). Two new ARN-namespace traps found, both confirmed against the service's own arn.Build call sites before wiring: VPC Lattice's real ARN service is "vpc-lattice", not "vpclattice" (services/vpclattice/store.go's arnService constant); Kinesis Data Analytics v2's ARNs use the real AWS "kinesisanalytics" namespace, not "kinesisanalyticsv2" (services/kinesisanalyticsv2/tags.go), which it shares with the separate, still-unwired kinesisanalytics (v1) service -- wiring v1 later needs the same registration-order ownership check wireTaggingDocDB/wireTaggingNeptune use for their shared "rds" namespace, not a plain registerTaggingService call, or it will shadow v2. RAM's real TagResource only ever tags resource shares (confirmed: TagResource checks only b.resourceShares, never the permission or invitation ARNs also built via arn.Build elsewhere in the package), so it uses a constant resource type rather than resourceTypeFromARN. CodePipeline mixes two ARN shapes in one flat store -- a bare-name pipeline ARN (no separator) and a colon-separated "webhook:{name}" ARN -- so a small codepipelineResourceType wrapper turns resourceTypeFromARN's bare-name fallback into an explicit "codepipeline:pipeline" instead of leaving it as the ambiguous service-alone string. Rekognition's resourceExists gate (already documented in rekognition/tags.go) is narrower than its arn.Build call sites: bare project ARNs are never accepted, only collection, stream processor, and project version ARNs are, matching the real API. AppStream only tags the resource kinds it seeds into its tag store at creation time (stacks, app blocks, fleets, applications, images); directory configs and users build ARNs too but are never seeded, so they can never be tagged. opsworks was examined and explicitly skipped: it has native tagging support and a real resourceExists gate already correctly scoped to stack/layer ARNs (per its own doc comment), but the service itself is never registered in cli.go's getServiceProviders chain at all -- no &opsworksbackend.Provider{} entry anywhere -- so it isn't a running service and wiring its tagging would be a no-op (byName["OpsWorks"] is always nil). fsx was also examined and skipped: every one of its CreateFileCache/CreateBackup/CreateDataRepositoryTask/CreateVolume/CreateFileSystem/CreateSnapshot/CreateStorageVirtualMachine functions takes an unexported *createXInput struct, so it cannot be exercised from cli_test.go via the established direct-backend-call pattern without adding HTTP-layer test scaffolding no other subtest in this table uses. s3control remains blocked as documented (bd: gopherstack-3xne).
• This pass (gopherstack-3xne, fifth sweep) wired 21 more: Comprehend, Shield, Transcribe, VerifiedPermissions, WAF Classic, SecurityHub, AppRunner, Route53Resolver, Timestream Write, S3 Tables, WorkMail, Pinpoint, Application Auto Scaling, CodeArtifact, Clean Rooms, App Mesh, Personalize, SESv2, X-Ray, AWS Config, and EventBridge Scheduler -- bringing the count from 69 to 91 (of the roughly 90 originally estimated; the true total was always an approximation). Each got a new TaggedResources() accessor. New ARN-namespace traps, each confirmed against the service's own arn.Build call sites: Timestream Write uses "timestream", not "timestreamwrite"; Pinpoint uses "mobiletargeting", not "pinpoint"; SESv2 shares the real "ses" namespace with SES v1 (which builds no ARNs of its own today, so unlike kinesisanalytics v1/v2 there is no registration-order collision to guard against yet); AWS Config uses "config", not "awsconfig" (hand-built ARN strings, not pkgs/arn); Application Auto Scaling's scalable targets build ARNs under the real "application-autoscaling" namespace while its scheduled actions and scaling policies build ARNs under "autoscaling" instead (matching real AWS's own historical split) -- but TagResource only ever resolves scalable targets, so only "application-autoscaling" is wired. Two new nested-ARN shapes needed the existing nestedResourceType helper ("parent/id/kind/id", already handled, no new helper needed): WorkMail nests users/groups/resources one level under their organization, Clean Rooms nests seven sub-resource kinds one level under their membership. App Mesh and S3 Tables needed dedicated derivation closures (appmeshResourceType, s3tablesResourceType) since App Mesh nests to varying depths (mesh -> virtualNode/virtualRouter/etc -> route/gatewayRoute, 2/4/6 segments) and S3 Tables nests a table under a namespace under a bucket (5 segments) -- both deeper than nestedResourceType's fixed 4-segment check. The acceptance-gate-narrower-than-arn.Build trap paid off twice more: Shield's TagResource never resolves protection-group ARNs (only protections), and Application Auto Scaling's TagResource never resolves scheduled-action or scaling-policy ARNs (only scalable targets). EXAMINED AND SKIPPED: forecast's only resource-creation path (b.create) is unexported and reachable solely from its own handler's JSON operation dispatch, not a direct backend method the established cli_test.go pattern can call -- wiring was written, then backed out once this was confirmed, rather than shipped untested. s3control remains blocked as documented (bd: gopherstack-3xne). NOT PURSUED, no code written: acm (tags live behind a Handler-level, not Backend-level, ARN dispatch spanning four distinct resource kinds -- not read deeply enough to confirm the pattern fits), amplify, apigateway (leading-slash "/restapis/{id}" ARN with no account segment), apigatewayv2, appsync (TagResource takes an apiID, not a full ARN), databrew, emrserverless (leading-slash ARN), iot (TagResourceGeneric's acceptance-gate breadth was not traced), iotanalytics, kafka, organizations (TagResource takes a bare resourceID, not an ARN, so the generic ARN-keyed dispatch needs an adapter that was not written), ssoadmin (TagResource takes both an instanceArn and a resourceArn, and its ARNs use the "sso" namespace), and textract -- see cli.go's wireResourceGroupsTagging doc comment for the current exact wired list.

Deferred

• Full TagsPerPage/ResourcesPerPage interaction edge cases beyond the cumulative-tag-count cap (e.g. exact AWS behavior when a single oversized resource's tag count alone exceeds TagsPerPage across multiple such resources in a row) -- current fix always keeps at least one resource per page, matching the 'never split a resource across pages' rule, but has not been stress-tested against arbitrarily adversarial tag-count distributions
• ResourceARN max-length (1011 chars per the real ResourceARN shape) is not validated in validateARNList; only structural parseability (awsarn.Parse) is checked. Low-value edge case, not exercised by any known test.

More

• Full parity audit
• All services