search

Azure / static-web-apps-cli

Azure Static Web Apps CLI ✨
https://aka.ms/swa/cli-local-development
MIT License
585 stars 112 forks source link

swa 1.0.3 with Node18 - Can't reach api endpoint #598

Open jouz3 opened 1 year ago

jouz3 commented 1 year ago

Describe the bug The last version of the swa cli (1.0.3) doesn't seem to work with NodeJS LTS 18.12.1 on a Blazor WASM with dotnet functions. The swa cli can't connect to the api endpoint, but it works outside the swa cli either by running it via swa start or func host start:

[swa] ✖ Could not connect to "http://localhost:7071/". Is the server up and running?

To Reproduce

> swa start http://localhost:5000 --run "dotnet watch run --project src/Client/Client.csproj" --api-location src/Api -V silly

Welcome to Azure Static Web Apps CLI (1.0.3)

Getting config file options from swa-cli.config.json...
Config file does not exist at <*****>\swa-cli.config.json
***********************************************************************
* WARNING: This emulator may not match the cloud environment exactly. *
* Always deploy and test your app in Azure.                           *
***********************************************************************

Checking if localhost:4280 is accepting TCP connections...
Port 4280 is available. Use it.
Resolved port number: 4280
appDevserverUrl provided, we will try connect to dev server at .
Trying to read workflow config with values:
 - appLocation: <*****>
 - outputLocation: http://localhost:5000
 - apiLocation: <*****>\src\Api
No workflow config folder found at <*****>\.github\workflows
Validating user workflow config (BEFORE):
 - appLocation: <*****>
 - outputLocation: http://localhost:5000
 - apiLocation: <*****>\src\Api
Validating user workflow config (AFTER):
 - appLocation: <*****>
 - apiLocation: <*****>\src\Api
 - outputLocation: http://localhost:5000
User workflow config:
 - appLocation: <*****>
 - apiLocation: <*****>\src\Api
 - outputLocation: http://localhost:5000
Starting the SWA emulator with the following configuration:
- ssl:
  - 0: false
  - 1: <undefined>
  - 2: <undefined>
- env:
  - SWA_RUNTIME_CONFIG_LOCATION: <*****>
  - SWA_RUNTIME_WORKFLOW_LOCATION: <undefined>
  - SWA_CLI_DEBUG: silly
  - SWA_CLI_API_PORT: 7071
  - SWA_CLI_APP_LOCATION: <*****>
  - SWA_CLI_OUTPUT_LOCATION: http://localhost:5000
  - SWA_CLI_API_LOCATION: <*****>\src\Api
  - SWA_CLI_HOST: localhost
  - SWA_CLI_PORT: 4280
  - SWA_CLI_APP_SSL: false
  - SWA_CLI_APP_SSL_CERT: <undefined>
  - SWA_CLI_APP_SSL_KEY: <undefined>
  - SWA_CLI_STARTUP_COMMAND: dotnet watch run --project src/Client/Client.csproj
  - SWA_CLI_VERSION: 1.0.3
  - SWA_CLI_SERVER_TIMEOUT: 60
  - SWA_CLI_OPEN_BROWSER: false
- commands:
  - swa: node "<*****>\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\msha\server.js"
  - api: cd "<*****>\src\Api" && func start --cors "*" --port 7071 
  - run: cd "<*****>" && dotnet watch run --project src/Client/Client.csproj
[run] dotnet watch 🔥 Hot reload enabled. For a list of supported edits, see https://aka.ms/dotnet/hot-reload. 
[run]   💡 Press "Ctrl + R" to restart.
[run] dotnet watch 🔧 Building...
[api] MSBuild version 17.3.2+561848881 for .NET
[api]   Determining projects to restore...
[run]   Determining projects to restore...
[swa] Loading staticwebapp.config.json schema...
[api]   All projects are up-to-date for restore.
[run]   All projects are up-to-date for restore.
[api]   Shared -> <*****>\src\Api\bin\output\Shared.dll
[run]   Shared -> <*****>\src\Shared\bin\Debug\net6.0\Shared.dll
[swa] Schema loaded successfully from https://json.schemastore.org/staticwebapp.config.json
[swa] Compiling schema...
[swa] Reading content from staticwebapp.config.json...
[swa] Parsing staticwebapp.config.json...
[swa] Validating staticwebapp.config.json...
[swa] File validated successfully. Continuing with configuration!
[swa] Content parsed successfully
[swa]
[swa] Found configuration file:
[swa]   <*****>\src\Client\wwwroot\staticwebapp.config.json
[swa]
[swa] Validating dev server config:
[swa]  - url: http://localhost:5000
[swa]  - timeout: 60
[swa] Checking if localhost:5000 is accepting TCP connections...
[swa] - Waiting for http://localhost:5000 to be ready
[api]   Api -> <*****>\src\Api\bin\output\Api.dll
[run]   Client -> <*****>\src\Client\bin\Debug\net6.0\Client.dll
[run]   Client (Blazor output) -> <*****>\src\Client\bin\Debug\net6.0\wwwroot
[api]   Determining projects to restore...
[api]   Restored <*****>\AppData\Local\Temp\rshjuuph.lof\WorkerExtensions.csproj (in 1 sec).
[run] dotnet watch 🚀 Started
[api]   WorkerExtensions -> <*****>\AppData\Local\Temp\rshjuuph.lof\buildout\Microsoft.Azure.Functions.Worker.Extensions.dll
[run] info: Microsoft.Hosting.Lifetime[14]
[run]       Now listening on: http://localhost:5000
[run] info: Microsoft.Hosting.Lifetime[0]
[run]       Application started. Press Ctrl+C to shut down.
[swa] ✔ Connected to http://localhost:5000 successfully
[run] infoValidating dev server config:
[run] : Microsoft.Hosting.Lifetime[0]
[run]       Hosting environment: Development
[run] info: Microsoft.Hosting.Lifetime[0]
[run]       Content root path: <*****>\src\Client
[swa]  - url: http://localhost:7071
[swa]  - timeout: 60
[swa] Checking if localhost:7071 is accepting TCP connections...
[swa] - Waiting for http://localhost:7071 to be ready
[api]
[api] Build succeeded.
[api]     0 Warning(s)
[api]     0 Error(s)
[api]
[api] Time Elapsed 00:00:07.15
[api]
[api]
[api]
[api] Azure Functions Core Tools
[api] Core Tools Version:       4.0.4865 Commit hash: N/A  (64-bit)
[api] Function Runtime Version: 4.12.2.19454
[api]
[api] [2022-11-08T11:47:39.657Z] Found <*****>\src\Api\Api.csproj. Using for user secrets file configuration.
[api]
[api] Functions:
[api]
[api]   <*****>: [GET] http://localhost:7071/api/<*****>/{culture}/{productItemKey}
[api]
[api]   <*****>: [GET] http://localhost:7071/api/<*****>/{subscriptionTicketKey}
[api]
[api]   Liveness: [GET] http://localhost:7071/api/Liveness
[api]
[api]   <*****>: [PUT] http://localhost:7071/api/<*****>
[api]
[api] For detailed output, run func with --verbose flag.
[api] [2022-11-08T11:47:42.497Z] Worker process started and initialized.
[api] [2022-11-08T11:47:46.312Z] Host lock lease acquired by instance ID '000000000000000000000000D3D4745D'.
[swa] ✖ Waiting for http://localhost:7071 to be ready
[swa] **✖ Could not connect to "http://localhost:7071". Is the server up and running?**
[swa] killing SWA CLI
[swa] node "<****>\AppData\Roaming\npm\node_modules\@azure\static-web-apps-cli\dist\msha\server.js" exited with code 0
--> Sending SIGTERM to other processes..
[run] cd "<****>" && dotnet watch run --project src/Client/Client.csproj exited with code 1
--> Sending SIGTERM to other processes..
[api] cd "<****>\src\Api" && func start --cors "*" --port 7071  exited with code 1
**✖ SWA emulator stoped because API server exited with code 1.**

image

Desktop (please complete the following information):

xxnickles commented 1 year ago

I second here. As discussed in #564 swa CLI is not working with functions 4 (.net SDK at least) using node 18 LTS, even after updating to .net7 on Windows 11. The "workaround" is using node 16, which works just fine

rupareddy5-21 commented 1 year ago

@jouz3, is it possible to share your repo details? Also, can you please retry the scenario and let me know if the issue persists because I tested the scenario and I didn't find any issue.

arobthearab commented 1 year ago

Same issue following "vanilla" static web site and api instructions precisely.

OS: OS X 13.0.1 (Ventura) swa cli Version 1.0.3 NodeJs Version: LTS 18.12.1 Azure Functions Core Tools Version: 4.0.4865

I can perform "swa start" which binds localhost:4280, or "swa start src --api-location api" which binds localhost:7071 but I cannot get both to occur following the directions in https://learn.microsoft.com/en-us/azure/static-web-apps/add-api?tabs=vanilla-javascript

I tried the following, prior to which the "swa start src --api-location api" command would fail to start the api server on localhost:7071:

sgollapudi77 commented 1 year ago

Hey @arobthearab , @jouz3 we're able to reproduce the same issue locally. Seems like something is breaking with azure function core tools v4 with Node18 installed. We're investigating this issue and will get back to you soon. Meanwhile please try to downgrade the version of Node 16. Please feel free to contribute if anyone has any discoveries. Thanks.

scafaria commented 1 year ago

This still fails for me on Node 16.

I can hit the web app at the 7175 port below. But if I try at 4280 it says "the site can't be reached". I am using Node 16 and Chrome on Windows 11. (Note: I'm new to this; following a tutorial). Thanks.

Here is the profiles node of my Client launchsettings.json. I've tried with and without the launchUrl delared.

"profiles": { "Client": { "commandName": "Project", "dotnetRunMessages": true, "launchBrowser": true, "launchUrl": "http://localhost:4280/", "inspectUri": "{wsProtocol}://{url.hostname}:{url.port}/_framework/debug/ws-proxy?browser={browserInspectUri}", "applicationUrl": "https://localhost:7175;http://localhost:5023", "environmentVariables": { "ASPNETCORE_ENVIRONMENT": "Development" } }

And here is the output

c:\PositiveSum\Code\Samples\Scratchest>swa start https://localhost:7175/ --verbose=silly

Welcome to Azure Static Web Apps CLI (1.0.3)

Getting config file options from swa-cli.config.json... Config file does not exist at c:\PositiveSum\Code\Samples\Scratchest\swa-cli.config.json

WARNING: This emulator may not match the cloud environment exactly. Always deploy and test your app in Azure. Checking if localhost:4280 is accepting TCP connections... Port 4280 is available. Use it. Resolved port number: 4280 appDevserverUrl provided, we will try connect to dev server at . Trying to read workflow config with values:

appLocation: c:\PositiveSum\Code\Samples\Scratchest outputLocation: https://localhost:7175/ apiLocation: No workflow config folder found at c:\PositiveSum\Code\Samples\Scratchest.github\workflows Validating user workflow config (BEFORE): appLocation: c:\PositiveSum\Code\Samples\Scratchest outputLocation: https://localhost:7175/ apiLocation: Validating user workflow config (AFTER): appLocation: c:\PositiveSum\Code\Samples\Scratchest apiLocation: outputLocation: https://localhost:7175/ User workflow config: appLocation: c:\PositiveSum\Code\Samples\Scratchest apiLocation: outputLocation: https://localhost:7175/ Starting the SWA emulator with the following configuration: ssl: 0: false 1: 2: env: SWA_RUNTIME_CONFIG_LOCATION: c:\PositiveSum\Code\Samples\Scratchest SWA_RUNTIME_WORKFLOW_LOCATION: SWA_CLI_DEBUG: silly SWA_CLI_API_PORT: 7071 SWA_CLI_APP_LOCATION: c:\PositiveSum\Code\Samples\Scratchest SWA_CLI_OUTPUT_LOCATION: https://localhost:7175/ SWA_CLI_API_LOCATION: SWA_CLI_HOST: localhost SWA_CLI_PORT: 4280 SWA_CLI_APP_SSL: false SWA_CLI_APP_SSL_CERT: SWA_CLI_APP_SSL_KEY: SWA_CLI_STARTUP_COMMAND: SWA_CLI_VERSION: 1.0.3 SWA_CLI_SERVER_TIMEOUT: 60 SWA_CLI_OPEN_BROWSER: false commands: swa: node "C:\Users\Vince Scafaria\AppData\Roaming\npm\node_modules@azure\static-web-apps-cli\dist\msha\server.js" api: run: [swa] No staticwebapp.config.json found in current project [swa] Validating dev server config: [swa] - url: https://localhost:7175/ [swa] - timeout: 60 [swa] Checking if localhost:7175 is accepting TCP connections... [swa] - Waiting for https://localhost:7175/ to be ready [swa] √ Connected to https://localhost:7175/ successfully [swa] [swa] Using dev server for static content: [swa] https://localhost:7175/ [swa] [swa] Azure Static Web Apps emulator started at http://localhost:4280/. Press CTRL+C to exit.

scafaria commented 1 year ago

I tried again with additional repro steps and hit a seemingly related issue: https://github.com/Azure/static-web-apps-cli/issues/609

renaudjmathieu commented 1 year ago

For me, the command swa start is working correctly (Connected to http://localhost:7071 successfully) until I run the command npm run dev or npx webpack serve. Then it won't work (Could not connect to "http://localhost:7071". Is the server up and running?) until I restart my computer. Then it works again, etc. 😕

nathantc commented 1 year ago

I was receiving the same could not connect message and discovered it was simply my host file not routing localhost.

I learned that swa uses the 'wait-on' library to check for the host. Maybe logging the error response from 'wait-on' is needed. I executed the wait on using npx:

npx wait-on -v http://localhost:3000

I received the following: 

making HTTP(S) head request to  url:http://localhost:3000 ...
  HTTP(S) error for http://localhost:3000 Error: connect ECONNREFUSED ::1:3000

Hope this helps!

My original error message:

[run] webpack compiled successfully
[run] Compiling...
[run] Compiled successfully!
[run] webpack compiled successfully
[swa] × Waiting for http://localhost:7071 to be ready
[swa] ✖ Could not connect to "http://localhost:7071". Is the server up and running?
[swa] node "C:\dev\node\node-v18.12.1-win-x64\node_modules\@azure\static-web-apps-cli\dist\msha\server.js" exited with code 0
--> Sending SIGTERM to other processes..
[run] cd "C:\dev\learning\vaesen-rpg" && npm start exited with code 1
--> Sending SIGTERM to other processes..
[api] cd "C:\dev\learning\vaesen-rpg\api" && func start --cors "*" --port 7071  exited with code 1
✖ SWA emulator stoped because API server exited with code 1.
dnkh commented 1 year ago

I have also the "Could not connect to "http://localhost:7071". Is the server up and running" issue when node 18 and swa 1.0.4 With node 16 and swa 1.0.4 everthing works as expected

phwecker commented 1 year ago

similar issue is blocking customer from using SWA cli as their policies prohibit use of node16, and require node18 ... any ETA on when SWA will be compatible with node18?

Reshmi-Sriram commented 1 year ago

Hi all, The team is currently investigating this issue and will keep you posted on our findings. Node 18 is still in public preview, so kindly bear with us while we investigate and figure out the compatibility. We are expecting to get the fix within a month. Meanwhile, please resort to Node 16. Apologies for the inconvenience!

dnkh commented 1 year ago

Hi all, The team is currently investigating this issue and will keep you posted on our findings. Node 18 is still in public preview, so kindly bear with us while we investigate and figure out the compatibility. We are expecting to get the fix within a month. Meanwhile, please resort to Node 16. Apologies for the inconvenience!

@Reshmi-Sriram Are you sure (regarding node 18 is in preview) ?

image

https://nodejs.org/en/

Reshmi-Sriram commented 1 year ago

Hi all, The team is currently investigating this issue and will keep you posted on our findings. Node 18 is still in public preview, so kindly bear with us while we investigate and figure out the compatibility. We are expecting to get the fix within a month. Meanwhile, please resort to Node 16. Apologies for the inconvenience!

@Reshmi-Sriram Are you sure (regarding node 18 is in preview) ?

image

https://nodejs.org/en/

Hey @dnkh, Apologies for the unclear message. Node 18 is in Public Preview in Static Web Apps, as you can see in this announcement.

xxnickles commented 1 year ago

Something I found odd is this issue with node 18 is happening in Windows 11 (in my case), but is working fine in Linux (Ubuntu) I am using the latest swa (1.0.6) btw

agravity-philipp commented 1 year ago

Is there any progress on that? Why can I not access port 4280 with both static web site and API via /api? Would need that...

AverageCakeSlice commented 1 year ago

I'd like to chime in as well. The issue seems sporadic for me, sometimes it'll work with Node 18, other times it'll just refuse to cooperate. If I run or debug the Functions app and get prompted for developer tools access after a reboot, etc, is when the swa cli seems to give up with Node 18.

Rebooting again after entering the password for the prompt seems to fix the problem and I can use Node 18 again. I can also use Node 16 via NVM without said reboot if I'm in a hurry.

danvdumitriu commented 1 year ago

In my case SWA couldn't "see" the function app, although it was working fine when I've accessed it directly in the browser. So the issue was while starting SWA like this:

swa start http://localhost:3000 --api-devserver-url http://localhost:7071

After spending some time to investigate, it turns out that this was related to this issue: https://github.com/nodejs/node/issues/40537

So to check if this is the case for you, try substituting "localhost" for "127.0.0.1", like this:

swa start http://localhost:3000 --api-devserver-url http://127.0.0.1:7071

Finally, in order to be able to still use "localhost", I've ended up changing the precedence of IP address resolution. On Windows (10), you can change the precedence of IP address resolution to prefer IPv4 over IPv6 by modifying the Windows registry. Here's how to do it:

  1. Press Win + R to open the Run dialog box.
  2. Type regedit and press Enter to open the Registry Editor.
  3. Navigate to the following registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters
  4. Right-click on the Parameters key, select New, and click on DWORD (32-bit) Value.
  5. Name the new value DisabledComponents and press Enter.
  6. Double-click the DisabledComponents value to open the Edit DWORD (32-bit) Value dialog box.
  7. In the Value data field, enter 20 (Hexadecimal) or 32 (Decimal) and click OK. This value will set the precedence of IPv4 over IPv6.
  8. Close the Registry Editor.
  9. Restart your computer for the changes to take effect.
rupareddy5-21 commented 1 year ago

Please feel free to track the original issue #663

AverageCakeSlice commented 1 year ago

Just wanted to follow-up and mention that you should also make sure you're not being dumb like I was and make sure you cd into the actual project directory first before running the tool. 🤦‍♂️

Though it would be nice if the CLI could mention that no SWA config was found or something to give the developer a hint.

yooakim commented 1 year ago

Same issue here, I am using Windows 11 and

After following @danvdumitriu 's advice making sure IPv4 had precedence over IPv6 everything works. So it seems as if the issue is related (in Windows) to the resolution of localhost to IPv6.

I guess that should work but something in the stack makes it not work.