anomalyco/sst · error · VisibleError

Cannot access the created function because it is referenced

Error message

Cannot access the created function because it is referenced as an ARN.

What it means

When a function is defined by an ARN string (an externally managed Lambda), SST only holds a reference to it and cannot resolve an inline Function resource. functionBuilder makes getFunction() throw a VisibleError because there is no locally created function to access.

Source

Thrown at platform/src/components/aws/helpers/function-builder.ts:68

  return output(definition).apply((definition) => {
    if (definition instanceof Workflow) {
      return buildResult(definition.getFunction());
    }

    if (definition instanceof Function) {
      return buildResult(definition);
    }

    if (typeof definition === "string") {
      // Case 1: The definition is an ARN
      if (definition.startsWith("arn:")) {
        const { unqualifiedArn, qualifier } = splitQualifiedFunctionArn(
          definition,
        );
        const parts = definition.split(":");
        return {
          getFunction: () => {
            throw new VisibleError(
              "Cannot access the created function because it is referenced as an ARN.",
            );
          },
          arn: output(unqualifiedArn),
          targetArn: output(definition),
          qualifier: output(qualifier),
          targetInvokeArn: output(
            `arn:${parts[1]}:apigateway:${parts[3]}:lambda:path/2015-03-31/functions/${definition}/invocations`,
          ),
          targetResponseStreamingInvokeArn: output(
            `arn:${parts[1]}:apigateway:${parts[3]}:lambda:path/2021-11-15/functions/${definition}/response-streaming-invocations`,
          ),
        };
      }

      // Case 2: The definition is a handler
      const fn = new Function(
        ...transform(

View on GitHub (pinned to a0bd20f762)

Solutions

  1. Use the arn/targetArn/qualifier outputs instead of getFunction()
  2. Create the function with SST (handler-based definition) if you need full function access
  3. Split your config so ARN-referenced functions are only used for IAM/policy wiring

Example fix

// before
const fn = "arn:aws:lambda:us-east-1:123:function:ext:1"
const f = fn.getFunction()
// after
const f = { arn: fn.arn, qualifier: fn.qualifier } // use arn outputs
Defensive patterns

Strategy: type-guard

Validate before calling

function canGetFunction(fn: unknown): fn is { getFunction: () => unknown } {
  return typeof fn === "object" && fn !== null && "getFunction" in fn && typeof (fn as any).arn !== "string";
}

Type guard

const isArnReferenced = (fn: any) => typeof fn === "string" && fn.startsWith("arn:");
// if isArnReferenced(def) use def.arn/qualifier, never def.getFunction()

Try / catch

try { return fn.getFunction(); } catch { return { arn: fn.arn, qualifier: fn.qualifier }; }

Prevention

When it happens

Trigger: Defining a component value as a qualified ARN string (e.g. fn: "arn:aws:lambda:...:function:x:1") and then calling .getFunction() or otherwise treating it as a locally built function (via createFunction, createIssuer, fn, createServer, builder).

Common situations: Pointing an SST component at an existing Lambda by ARN and later trying to read function metadata (name, url, etc.) as if it were created by SST.

Related errors


AI-assisted analysis of anomalyco/sst@a0bd20f762 (2026-08-30). Data as JSON: /api/errors/ee1be2cf6a28fb5d. Report an issue: GitHub.