start-api automatic reload does not appear to be doing anything

[ryancole]

Hi folks,

I'm running the following command: sam local start-api

I'm running the above command inside of a directory that I created using the sam --init command. So, it's a directory with a template.yaml file in it, and an actual node.js lamba function project folder.

The console output from sam says that I do not need to restart the CLI for changes to take affect, but modifying my code does not appear to cause any sort of automatic reload.

Do I have to do anything specific to allow this to auto reload? I'm running Windows 10.

[jfuss]

You will need to build every time. The behavior is you do not need to restart the command and can update the folders with new code and have it reflected when hitting the api. With the introduction of sam build, you will need to build anytime your source or dependencies change. We are looking to make this easier with sam build --watch but that will not change the behavior of the sam local start-api command.

Closing as this is working as intended.

[felixhageloh]

when I run sam local start-api I get this output

You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template

Which suggests that automatic reloading is the intended behavior

[jfuss]

@felixhageloh Yes but that 'auto reloading' is not 'auto building'. The reloading in this is describing that you can update the contents of the CodeUri and see the changes without restarting the api. With the introduction of sam build, this notion changed slightly.

If you are using build, what this is saying is you can build the function without needing to restart. This is because build generates a template that is used behind the scenes that points to a build location. The confusion comes from, you as a customer only interact with the non-built function/template while the invoke can (if using build) interact with the generated built template. Maybe a rewording is in order here to make the expectation better but it is working as intended.

I create #921 to track the work for 'auto building' through sam build --watch.

Note: That output was from the pre-sam build stage.

[felixhageloh]

@jfuss thanks for the clarification. I spent some time reading the docs in the meantime and they also all clearly state that you need to run build again.

[eamarce]

Hey guys,

So, we created a small npm package based in nodemon (samwatch):

https://www.npmjs.com/package/samwatch

https://github.com/mxitgo/samwatch

The way it works is, it copies your js/json files as you save them from the source folder to the corresponding .aws-sam/build folder (as long as the names are the same for your lambda and the code uri in template.yaml).

That is useful to see your changes reflected on the fly if you are running sam local start-api, so you don't have to run sam build after every change.

On the other hand, if the corresponding file copy is not within the .aws-sam/build folder already, the package will trigger a sam build (unless you use n parameter).

The package has helped us get a hot reload feeling for our local lambda function development with sam.

I hope anyone can find it useful.

Thanks!

[Cunaguaro]

Hi @felixhageloh. maybe it is too late now but it can help to solve this issue.
I note that when I run "sam local invoke getHomePage", the path in the container volume load the .aws-sam/build folder. that indicates that hot-reloading never going to work because the container is mounting the build folder. that's is why you have to run "sam build" every time.

Mounting /media/valero61/SWA/ubuntu/workspace/cunaguaro product cataloge/.aws-sam/build/getHomePage

I deleted the build folder and run sam local invoke getHomePage, now container mounts the path to the root folder of the project. and now hot-reload is working again.

Mounting /media/valero61/SWA/ubuntu/workspace/cunaguaro product cataloge as /var/task:ro,delegated inside runtime container

[alex-nishikawa]

For local development I remove the .aws-sam build folder:

"start:local": "rm -r .aws-sam & tsc -w && sam local start-api"

I do watch for typescript compilation during hot-reloading.

To answer your question @ryancole,
sam local start-api looks for changes in the .aws-sam folder IF it exists, if not, then it looks for changes in the root directory of your project.

[jthomerson]

@jfuss I understand now that this is intended behavior, but could I suggest that you at least re-word the output of the local start-api command? It caught me, too

Eventual hot-reloading would be nice, but for now, please don't confuse brand new users with the message that implies hot-reloading.

[alex-nishikawa]

@jthomerson

The confusion is that sam local start-api will always pull from the .aws-sam folder IF it exists. If you remove that folder you really do have hot-reloading, i.e. any saved code changes will be reflected in the lambda WITHOUT having to call start-api again.

This was confusing though, and I can't remember if the documentation mentions this.

[jthomerson]

Fascinating. Thanks for the tip @alex-nishikawa! I still think that message in the SAM start-api output should be more clear about this, but at least now I learned 😁

[jjercx]

The confusion is that sam local start-api will always pull from the .aws-sam folder IF it exists. If you remove that folder you really do have hot-reloading, i.e. any saved code changes will be reflected in the lambda WITHOUT having to call start-api again.

This is true, what how does it work with the dependencies? I'm using ruby and even after running bundle install --path vendor/bundle the function doesn't seem to pick the gems

[jfuss]

The statements about where sam local start-api pulls from are incorrect. sam local start-api (like all other sam local commands) 'pull' from the location that is specified in the template. What you are actually referring to is that all of our commands look for a template located in .aws-sam/build. This was done so customers do not need to specify the built template directly.

Regardless, if you use sam build, you need to build after changes to have them reflected.

[stevenlafl]

--watch option appears to be removed from sam build making this even more cumbersome.

$ sam build --watch
Usage: sam build [OPTIONS] [FUNCTION_IDENTIFIER]
Try 'sam build --help' for help.

Error: no such option: --watch
$ sam --version
SAM CLI, version 1.15.0

[codeedog]

@jfuss

Forgive my ignorance and inexperience, but what is the value of sam build? Not what does it do, but why does it exist? I'd much prefer to have hot recompilation of my code during sam local start-api. In order to get any new code changes once I've already built a system, I have to kill the locally started api, build, then restart the local api. Why not just either (1) ignore the build directory from local start-api and integrate the build step into sam deploy? Or, automatically call sam build during the running start-api?

I can't think of any reason I'd want to have edited source code in my source tree with a running sam local start-api pointed at a prior version of the source build. That current running server would be what I'm testing against for the source code I'm actively editing and writing. Having two separate sources of truth feels terrible to me.

SO, what am I missing? There must be a good reason you've chosen to provide this separation of commands. You've written above "...but it is working as intended". I don't think anyone doubts it works as intended, what I'm (and others likely are) curious about is why you intend it to work this way?

What is the workflow that requires this behavior?

Thanks.

[tansanDOTeth]

For what it's worth, it seems this is the first link for the phrase aws sam hot reloading not working in Google. I would have also expected the code to recompile and automatically reload.

You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions, changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template.

Here is another relevant thread: #1921

[Fusseldieb]

For what it's worth, it seems this is the first link for the phrase aws sam hot reloading not working in Google. I would have also expected the code to recompile and automatically reload.

Ahahaha! This was the exact same Google Search I just did and landed here. Yes, I agree, this message is overly confusing. I also weren't sure why my project wasn't hot reloading. After reading this, seems like sam just can't do this just yet. Sad.

[ghost]

I also came across this recently, hoping to get hot reload type functionality to make local development with the AWS Serverless services easier.

I've seen some other work arounds on other aws-sam-cli Github issues saying an option is to move your dependencies into a Lambda layer, or to develop against the .aws-sam build artefacts and copy back over to the actual code directory once done... both of which just seems cumbersome compared to our current build process using CDK (CDK handles bundling of dependencies from requirements.txt, similar to how sam build does I guess)

Even though this is a super old issue I thought I'd comment incase it's of use to someone else.

I came up with this semi hack to get sam build to run on python file changes changes, this could be changed to suit other languages as needed.

1. Install fswatch (This is cross platform, but the below command wont't work on windows)
2. fswatch -r -0 $(find <lambda directory path> -type f '(' -name "requirements.txt" -o -name "*.py" ')') | xargs -0 -n 1 -I {} sh -c 'sam build -t <template file location>

where:
<lambda directory path> is the directory that contains the code (or code directories) for your Lambda function/s that are used behind API Gateway'
<template file location> is the sam template.yaml or the CDK stack json output ie cdk.out/APIStack.json

Note - the above command will run continually if your sam build command outputs .aws-sam into the <lambda directory path>, caught me when I initially pointed it at the root of my repo!

I'm using find over the built in file/dir inclusions and exclusions available in fswatch as I already had it handy in another script.

This at least reduces the time spent trying to figure out why your code changes aren't being reflected when calling the local SAM API endpoint, because you simply forgot to run sam build 😁 .

[shzxcv]

If your project uses Golang, you can work with air to solve this problem.

.air.toml

[build]
  cmd = "sam build"
  # Do nothing with the build
  bin = "/usr/bin/true"
  include_ext = ["go"]

Makefile

start:
	(air &) && (sam local start-api &)

stop:
	ps | grep -e "[a]ir" -e "[s]am local start-api" | awk '{print $$1}' | xargs -I @ kill -9 @

[zachbresler21]

Using sam local start-api requires restarting the server for every change, which is really disrupting the flow of development. Could we add an automatic build step to handle changes dynamically? This would make development smoother and keep us from having to restart manually all the time. Obviously, I think this might be the intended functionality but when using SAM build it doesn't work - anyway around this?

I might have missed something in this thread so please let me know if there was a solution to this issue.

[alecguintu]

If your project uses Golang, you can work with air to solve this problem.

.air.toml

[build]
  cmd = "sam build"
  # Do nothing with the build
  bin = "/usr/bin/true"
  include_ext = ["go"]

Makefile

start:
	(air &) && (sam local start-api &)

stop:
	ps | grep -e "[a]ir" -e "[s]am local start-api" | awk '{print $$1}' | xargs -I @ kill -9 @

Currently I use the same as what @shzxcv mentioned but instead of both running on background, I only background air

local-start:
	(air &) && sam local start-api

so I can still debug and when I ctrl+c both cancels as well. No need to stop