AWS tries to read config from file system

Question

I'm trying to send an email using AWS SES from a Supabase cloud function. I've set up the AWS env variables, but it still tries to read the config from filesystem, which fails 'cause there's no filesystem in the edge runtime?

The env vars I set are:

AWS_ACCESS_KEY_ID=key
AWS_SECRET_ACCESS_KEY=secret
AWS_REGION=us-east-2
AWS_DEFAULT_REGION=us-east-2
AWS_DEFAULT_PROFILE=default
AWS_SDK_LOAD_CONFIG=

I know some of these vars are redundant but, I'm trying everything at this point.

The error I keep getting is:

runtime has escaped from the event loop unexpectedly: event loop error: TypeError [ERR_INVALID_ARG_TYPE]" argument must be of type string. Received null
    at assertPath (ext:deno_node/path/_util.ts:10:11)
    at join (ext:deno_node/path/_posix.ts:77:5)
    at getCredentialsFilepath (file:///tmp/sb-compile-edge-runtime/node_modules/localhost/@smithy/shared-ini-file-loader/2.3.1/dist-cjs/index.js:75:117)
    at loadSharedConfigFiles (file:///tmp/sb-compile-edge-runtime/node_modules/localhost/@smithy/shared-ini-file-loader/2.3.1/dist-cjs/index.js:132:22)
    at file:///tmp/sb-compile-edge-runtime/node_modules/localhost/@smithy/node-config-provider/2.2.1/dist-cjs/index.js:51:105
    at file:///tmp/sb-compile-edge-runtime/node_modules/localhost/@smithy/property-provider/2.1.1/dist-cjs/index.js:79:33
    at eventLoopTick (ext:core/01_core.js:183:11)
    at async coalesceProvider (file:///tmp/sb-compile-edge-runtime/node_modules/localhost/@smithy/property-provider/2.1.1/dist-cjs/index.js:106:18)
    at async file:///tmp/sb-compile-edge-runtime/node_modules/localhost/@smithy/property-provider/2.1.1/dist-cjs/index.js:117:20

which looks like it forgets that the secrets are in env.

Finally, and maybe most importantly, when I run this:

import {
  SESClient,
} from "npm:@aws-sdk/client-ses";
client = new SESClient();
console.log(await client.config.credentialDefaultProvider()());

it actually logs the access key and secret, so, why it still throws the runtime error BAFFLES me

And of course, passing the credentials directly doesn't work either.

Answer 1

OK, it seems when loading the @aws-sdk/client-ses package in a "node-like" environment it goes down the path of loading the node-config-provider which then leads to loading the shared-ini-file-loader

This shared-ini-file-loader relies, as the name suggests, on the functionalities of a file system. The given stacktrace points to this line of code

var getCredentialsFilepath = /* @__PURE__ */ __name(() => process.env[ENV_CREDENTIALS_PATH] || (0, import_path.join)((0, import_getHomeDir2.getHomeDir)(), ".aws", "credentials"), "getCredentialsFilepath");

where it is trying to determine a home directory, which of course doesn't exist if there is no file-system. You could probably prevent this call to getHomeDir() here by setting the ENV_CREDENTIALS_PATH to some dummy value. This might be enough to bypass that error. But it also may just allow you one further step before failing somewhere else with the next function trying to access the file system. I have no environment where I can reproduce this, so this may or may not work, but it seems worth a try ...

Answer 2

Looks like the version on esm.sh has a different behavior and that worked.

All I had to do was point my import at esm.sh and manually get my creds from env like so:

import {
  SESClient
} from "https://esm.sh/@aws-sdk/[email protected]";

client = new SESClient({
    region: "us-east-2",
    credentials: {
      accessKeyId: Deno.env.get("AWS_ACCESS_KEY_ID"),
      secretAccessKey: Deno.env.get("AWS_SECRET_ACCESS_KEY"),
    },
});

I had no idea behavior could change based on importing from esm or directly from npm