feat(sam-app): add parameter to optionally override the sfInvokeApi Lambda Timeout

[Horgix]

Issue #, if available:

None

Description of changes:

Problem statement

When deploying this SAM stack in order to connect Amazon Connect with Salesforce, we often found that the sfInvokeAPI Lambda was resulting in timeouts - not by much, yet frequently enough for it to be an issue.

Given its timeout defaults to the one define as a Global for all the Lambda functions (that wouldn't have it overridden) in the stack, it means we were unable to specifically increase this one.

As of now, we have the following hack as a pre-hook in our tool (Spacelift) that handles this stack's deployment:

  before_init = [
    "wget https://github.com/mikefarah/yq/releases/download/v4.46.1/yq_linux_amd64.tar.gz -O - | tar xz && mv yq_linux_amd64 /tmp/yq",
    "/tmp/yq e '.Resources.sfInvokeAPI.Properties.Timeout = 20' sam-app/lambda_functions/template.yaml -i",
    "echo '.Globals.Function.Timeout overridden from default 6sec to 20sec'"
  ]

We'd very much favor just defining a parameter through an environment variable, just like we do for the rest of the parameters.

Proposed solution

This PR introduced a SfInvokeApiTimeout optional parameter that is used for the sfInvokeAPI Lambda if found - and otherwise default to the Global. That means that it doesn't change anything for existing users, and allows the ones who need to increase it to do so specifically.

Happy to discuss the proposed change or learn about another option we might have missed!

Note: I'm also sharing this PR with our AWS TAM and SA along the way

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[Horgix]

Hey @vrein-aws @sderacy, it's been a while so I'm pinging the last 2 commiters just to know if that has any chance of getting merged at some point of if I should just fork the repo and work on the fork instead 🙂

[LorneCurrie]

Hey @vrein-aws @sderacy, it's been a while so I'm pinging the last 2 commiters just to know if that has any chance of getting merged at some point of if I should just fork the repo and work on the fork instead 🙂

I doubt there will be much happening here. Have you opened a ticket via AWS console to see if you get a quicker response?

[vrein-aws]

Hi @Horgix — thanks for your patience and for following up! To move forward with these changes, could you open a support ticket through the AWS console? We'll need to run internal testing before we can merge into the master branch.

Alternatively, if these changes are specific to your project's needs, you're also welcome to fork the repo and work from there — that way you'd have full flexibility to customize as needed without waiting on us.

Let us know which route works best for you!