Network connectors (Lambda Core service)

[lex00]

All five Lambda Core operations, the PENDING → ACTIVE state machine on the clock, the asynchronous DELETING window, and an injection lever for each of the seven reason codes. Based on main.

Connectors are a second service model, not a second resource: different API version, different URI family, and PascalCase members where Lambda Microvms uses lowercase.

Three things the model would have led me to get wrong

All three surfaced by running the recorded fixtures against a real implementation — the same class the handoff warned about, and the reason I ran conformance before believing any of it.

Bad requests come back two ways. Model constraints — list lengths, enum membership — are answered by a validation layer in front of the service, as ValidationException in AWS's standard wording, with the member path in camelCase even though every wire member is PascalCase:

1 validation error detected: Value '[subnet-…, …]' at
'configuration.vpcEgressConfiguration.subnetIds' failed to satisfy constraint:
Member must have length less than or equal to 16

ValidationException is not listed as an error of any connector operation in the Lambda Core model. The four enforced-but-modeled-optional members are service logic instead, and come back as InvalidParameterValueException with prose.

That layer runs first, and in full. Precedence was the one thing I had assumed was m80's to choose. It isn't. The too-many-subnets probe sent seventeen subnets and omitted ClientToken, OperatorRole, NetworkProtocol and AssociatedComputeResourceTypes — four of the enforced members missing — and the service still answered about subnetIds. validate now runs constraints to exhaustion before the service's required-member logic gets a look.

Not-found uses a capital Message — Lambda Core's own member style, not the lowercase message the other service uses — and echoes the ARN it built from whatever identifier arrived rather than the identifier itself.

Modeled optional, enforced anyway

ClientToken, OperatorRole, NetworkProtocol, AssociatedComputeResourceTypes. A client written from the model alone gets four 400s in a row. ClientToken is the strangest: the model marks it optional and tags it idempotencyToken, which normally means the SDK generates one for you.

Response shapes

Four responses, four different member sets — the model, not an accident of recording. Create and Delete return a base six; Get adds LastModified and the state/update status members; Update adds LastModified and update status but not StateReason; only the list summary carries Type. Absent means absent: a connector that has never been updated has no LastUpdateStatus at all, and emitting one as null would diverge on every read. List omits NextMarker entirely, so a client looping until the marker is null would loop forever.

The injection lever

The seven NetworkConnectorStateReasonCode values are the point. None can be provoked against real AWS on demand — you cannot ask EC2 to run a subnet out of addresses — so without injection a consumer's whole error-handling path stays untested, and KubeMicroVM's MicroVMNetwork reconciler has visible handling for them. One test per code; the lever is consumed on use so one failing connector does not poison a suite running several.

It is a Go API, matching the images build lever. I deliberately did not add m80-only cases to the conformance suite — that suite is a fidelity instrument measured against real AWS, and injected failures have no recorded fixture and never could. The acceptance's "one injected failure per reason code" is met by unit tests. If you want the lever drivable over HTTP for #18's offline drift UAT, that is a small addition and probably belongs with the rest of the drift levers.

Result

66 pass, 0 fail, 27/29 operations exercised, up from 58 and 24. Only ListTags and UntagResource remain, both #14. go build, go vet, gofmt, go test -race clean.

Closes #13