I'm seeing an odd occurence when using a cron-base...
# sst
r
I'm seeing an odd occurence when using a cron-based lambda with SST. When I fire up SST start, the target lambda gets hit multiple times, it almost seems to be that the SST somehow initiates a separate cron invocation in addition to the eventbridge rule/cron. The rate is deliberately set quite low - (every 5 minutes) so invocations don't overlap when debugging. Has anyone seen anything similar?
d
what's your cron rule set to? i thought yesterday a cron job was running on initialization, but turns out i had a bad rule.
r
It's
Copy code
schedule: 'rate(3 minutes)',
Copy code
const populatorCron = new sst.Cron(this, 'OmwPopulatorCron', {
      schedule: 'rate(3 minutes)',
      job: {
        handler: 'src/main/handlers/populator.startLookingForMissingUrls',
        environment,
        timeout: 60,
      },
    });
d
looks correct to me. 😢
r
shame 😞
I'm going to try to remove the stack and debug on 1st deploy to see what happens
Yeah, seems to happen only after starting, stopping and restarting
sst start
f
Hey @Ross Coundon, hmm.. my gut feeling is that when
sst start
isn’t running, cron lambda would fail b/c it can’t connect to a local debugger, and retries twice.
When it happens again, can you check the CloudWatch logs for the cron lambda and see if some invocations are retries of previously failed invocations. They would have the same request id.
r
Will do, cheers
f
@Ross Coundon I managed to reproduce the issue. It’s indeed retries from previously failed requests. I put in a fix in v0.23.0 to disable Lambda retries when deployed via
sst start
. Lambda timeout also gets extended to 15min (the max) to give ppl more time to debug using break points.
r
That's excellent, thanks Frank. Can you guys think of a way to extend the timeout for an API Gateway backed lambda beyond 30 seconds? I've been thinking about it myself but can't come up with anything, if that were possible, it'd be a real game changer for local development.
f
Yeah, we might need to hack around this… something real hacky on top of my head is for the API to return a 301 redirect, and it will keep redirecting until the local Lambda respond… lol it’s kinda dumb
I will an eye out for ways to get around the APIG limit
r
One man's dumb is another man's genius