https://serverless-stack.com/ logo
Join Slack
Powered by
Today, I was presenting SST to my colleagues and I...
# help
j
Today, I was presenting SST to my colleagues and I absolutely don't have a clue why, but the change detection suddenly doesn't work for any existing function. If I add new function, it works, watcher pickups changes. When I restart 
sst start
it works no longer even for the previously added function. EDIT: It does not work to anyone of us, it doesn't seem to be a local issue. I use both explicit Function creation and the ones scaffolded by SST from function props, neither works. EDIT 2: Found out what's wrong. The changes are picked up correctly (based on 
sst-debug.log
), but it won't rebuild/reload the function unless you hit the endpoint with a request at least once. Is this by design?
t
What's your directory structure
Oh wait yes, the functions are lazy built
We don't build them until they're used once, helps when you have a large number of functions but only working on a few at a time
j
Just a nitpick, but it would be nice if it would print the usual 
Functions: Building ...
during that first request lazy build. However we hit a more serious problem probably related to this:
The live reload doesn't work for authorizer lambda function, until at least one request successfully gets through the authorizer to the endpoint lambda.
So you basically can't use live reload to develop lambda authorizer.
t
I'm not sure I'm following, what value is there in rebuilding it if nothing has called it?
j
Say you have an authorizer that only returns 
{ isAuthorized: false }
and is connected to a route. Now you 
sst start
. Now you can modify the authorizer however you want, you can hit the end point and it just returns unathorized. The authorizer function never re-builds if you change it. We theoretize it's because the lambda behind the authorizer is never invoked...
If you start with an authorizer that always returns isAuthorized: true, it stars rebuilding the authorizer after the first request, because it reached the lambda endpoint.
t
are you sure the authorizer isn't set to liveDev false
It's odd because the authorizer is just like any other lambda, it gets built when invoked. If files are changed it'll be rebuilt so the next invocation is running the latest code
we don't build it on start
so in the first case on first request we're building it for the first time on the first request
j
That's what we assumed, but it didn't seem to be the case, however I will double check tomorrow.
My apologies, it seems to work fine. The problem was, we did not send the authorization header when testing it, so the request was stopped by AWS even before hitting the authorizer function. Sorry again for bothering.
2 Views
Open in Slack
PreviousNext
Powered by