🎙️ task - feat: pull invokeLambdaForTesting + invokeHandlerForTesting into the sdk (off aws-sdk v2)

[uladkasach]

🦫🎙️ dispatch to foreman

💧 task enqueued
   ├─ priority = ?
   ├─ yieldage = ?
   └─ leverage = ?

title
feat: pull invokeLambdaForTesting + invokeHandlerForTesting into the sdk (off aws-sdk v2)
description

feat(sdk-aws-lambda): pull the lambda-testing utils into the sdk

.what

pull the lambda test-invoke utils that today live in simple-lambda-testing-methods into
sdk-aws-lambda itself, so a consumer of the sdk gets one home for both the runtime invoke and
the test invoke:

• invokeLambdaForTesting({ service, function, stage, locally, event }) — invoke a live deployed
  lambda (or, with locally: true, the in-process handler via the serverless.yml handler path).
• invokeHandlerForTesting({ handler, event }) — invoke a callback-pattern handler with
  async/await, for unit/integration tests.

.why

1. one sdk, one home — a consumer already reaches for sdk-aws-lambda for the runtime invoke;
   the test invoke sits beside it, not in a separate simple-lambda-testing-methods package a
   consumer must discover independently.
2. share the invoke client + name computation — invokeLambdaForTesting builds the deployed
   function name from { service, function, stage } and invokes via a lambda client. that name
   computation + client is exactly what the sdk owns; a fork of it in a testing package invites
   drift (the two can disagree on how a function is named).
3. the aws-sdk version is a shared concern — the testing package currently pulls aws-sdk
   v2 under the hood (via simple-lambda-client), which has no SSO-profile support and hangs on
   IMDS for a dev-machine invoke (this bit us on ahbode/svc-home-services PR 🎙️ task - fix(errors): an absent schema.output is a raw TypeError in three places — refuse at construction and name the fix #30 — the deployed
   acceptance grain hung 90s/invoke until creds were exported to env vars). with the invoke client
   in the sdk, the sdk owns the aws-sdk version + credential-chain behavior in one place, and a fix
   there fixes both runtime and test invoke.

.the ask

• expose invokeLambdaForTesting + invokeHandlerForTesting from sdk-aws-lambda (names may be
  adjusted to the sdk's verb conventions, e.g. an invoke*/get* form — the point is the util,
  not the exact name).
• reuse the sdk's own lambda client + function-name computation so the test invoke and the runtime
  invoke cannot drift.
• on the aws-sdk version: prefer aws-sdk v3 (SSO-profile aware) so the invoke client does not fall
  back to IMDS on a dev machine. if v2 must stay for now, document the SSO caveat and the
  cred-export workaround the deployer deploy.sh uses.
• keep simple-lambda-testing-methods as a thin re-export shim for back-compat, or mark it
  deprecated in favor of the sdk export.

.acceptance

• a consumer can import { invokeLambdaForTesting } from 'sdk-aws-lambda' (or the sdk's chosen
  name) and invoke a deployed lambda + an in-process handler, with no separate testing package.
• the test invoke and the runtime invoke share the sdk's function-name computation + lambda client.
• the invoke client does not hang on IMDS for an SSO-profile dev-machine invoke (v3), or the SSO
  caveat + workaround is documented (v2).

.origin

surfaced as ahbode/svc-home-services (PR #30) built its deployed-acceptance grain on
invokeLambdaForTesting from simple-lambda-testing-methods; the aws-sdk-v2 SSO/IMDS hang and the
separate-package discovery cost both pointed at the util's home being sdk-aws-lambda. companion
to the git.repo.test acceptance-cloud cred/ACCESS dispatch (which works around the v2 hang at the
skill layer) and the declapract prep-over-dev dispatches.