feat: add new caching route lambda for async routing invocation

[jsy1218]

we want to try creating a new caching routing lambda for async lambda invocation, that will not get exposed through the api gateway. this separates the live path from the async path through two different routing lambdas.

On my local routing dashboard, I tuned all cached routes rollout percent to 100%. I can see the caching intent charts are still there:

I also added a test to assert against the spied metric that hits the new caching routing lambda

[jsy1218]

• feat: add new caching route lambda for async routing invocation #887 👈
• chore: bump sor to 4.7.5 - fix: cached routes cache invalidation #869
• chore: bump sor to 4.7.0 - feat: SOR level implementation to support 1) expanding mixed quoter v1 to L2s 2) support migrate mixed quoter v1 to mixed quoter v2 across chains #868
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @jsy1218 and the rest of your teammates on Graphite

[socket-security]

No dependency changes detected. Learn more about Socket for GitHub ↗︎

👍 No dependency changes detected in pull request

[graphite-app]

Graphite Automations

"Request reviewers once CI passes on routing-api repo" took an action on this PR • (10/28/24)

4 reviewers were added and 1 assignee was added to this PR based on 's automation.

[cgkol]

I think we need a test to confirm that the right lambda is invoked, otherwise we are good

[xrsv]

that's a good starting point - i was thinking if it's possible/easy for the caching lambda to only execute logic related to cache update, instead of the entire handler code. We can discuss offline.

[jsy1218]

yea lets discuss offline, im also thinking about how to write a test that can assert it invokes the caching lambda