Can I see

sst.Cron

instances in AWS? I've got some basic code and it doesnt seem to be working and I'm not sure how to debug it 🤔

what does your Cron definition look like?

export const cron = (stack: sst.Stack): sst.Cron =>
  new sst.Cron(stack, path, {
    schedule: Duration.minutes(10),
    job: path,
  });

I have it located next to the lambda itself and then I'm doing

[...userCrons].forEach((cron) => cron(this));

In the Stack constructor.

don’t think so. is

path

just a string locating the src file?

yes

I could be wrong, but I think that will wind up creating duplicate Lambda functions. I had that issue with API routes.. I had two different routes using the same Lambda, and it tried to create it twice. try creating the function first,

const myFunc = new sst.Function(…)

and then passing that to

job

Okay thanks 👍

We do it like this, define a Function then reference it in the Cron definition

const someCron = new sst.Cron(this, 'TheCron', {
      schedule: 'rate(5 minutes)',
      job: {
        function: theFunction,
      },
    });

Thanks. Can you add functions like that in app sync?

api.addResolvers(this, {
  "Query    listNotes": listNotesFunc,
  "Mutation createNote": "src/create.main",
});

Sorry, I'm not familiar with AppSync

also, string definitions don't need

this

in scope...

new Function

does 😕

@Alex Price yes, for resolvers you can do the same thing. looking at the TypeScript definition:

readonly resolvers?: {
        [key: string]: string | FunctionDefinition | AppSyncApiResolverProps;
    };

you can pass a

FunctionDefinition

, which also includes an

sst.Function

Nice. It's still pretty ugly, having to pass the stack

this

ctx around 😕 Any better solutions?

unfortunately with SST & CDK, there’s a bit of dependency injection, yeah. just the way it is

hmm @Alex Price this looks right to me, did u manage to get it to work?

export const cron = (stack: sst.Stack): sst.Cron =>
  new sst.Cron(stack, path, {
    schedule: Duration.minutes(10),
    job: path,
  });

@Frank wouldn’t using

path

(a string) create duplicate functions? I had issue with

sst.Api

so I had to create an

sst.Function

and pass that instead

Sorry, i mis-read the code, @Sam Hulick is right this shouldn’t work 😅

This does work.. but not when the handler is used else where (as a resolver for AppSync in case)

Does

someCron

only getting called once per stack?

In terms of code, it does now!

Right.. you will get an error when called more than once per stack as @Sam Hulick suggested, b/c you can’t have multiple cron jobs with the same name

Cron

in the same stack

Yup!

And what’s the error you are getting?

I'm not 😆

Oh gotcha.. my bad😁

@Alex Price be aware of your resource count if you have a stack with a lot of resolvers. for each resolver (the way you’re defining them), I believe it’ll create a single Lambda data source. you can create a handful of data sources elsewhere in the code (maybe separated by concern) and then point the resolvers to those, e.g.:

resolvers: {
      'Mutation createEvent': 'trackingDS',
      'Mutation createSession': 'trackingDS',
      'Mutation updateTranscodeStatus': 'trackDS',
    },

Thanks Sam! Yeah I believe there is guidance for splitting stacks out in the pipeline @Frank? in terms of docs*

Yeah, for example, this will create 2 data sources, 1 for each resolver:

api.addResolvers(this, {
  'Query getFoo': 'src/foo.main',
  'Mutation createFoo': 'src/foo.main',
});

While this will create 1 data source, shared by both resolvers:

api.addDataSources(this, {
  fooDS: 'src/foo.main',
});

api.addResolvers(this, {
  'Query getFoo': 'fooDS',
  'Mutation createFoo': 'fooDS',
});

Good to know. Our current set up is to have one handler per resolver, but I guess we'll hit the limits pretty fast. We could have seperate files for each resolver, and one DS which collates those into a single lambda 🤔