Live demoes not working

[antweiss]

Tried running the live demo referenced in this article. The demo is here: https://second-state.github.io/wasm-learning/faas/regex/html/index.html Received: {"return_value":"Error executing this function, please check function name, input parameters, return parameter for correctness"} Same with this demo: https://second-state.github.io/wasm-learning/faas/hello/html/index.html

[alabulei1]

Hi @antweiss

Thanks for your feedback. It seems the demo web page has a stale ID for the deployed function. I followed the tutorial to build and deployed a new function and it worked. We will update the demo page soon.

azureuser@vivian2021:~/wasm-learning/faas/hello$ curl --location --request POST 'https://rpc.ssvm.secondstate.io:8081/api/run/475/say' \
> --header 'Content-Type: text/plain' \
> --data-raw 'Second State FaaS'
hello Second State FaaS

[alabulei1]

Hi @antweiss ,

The live demo you mentioned works now. I'm working with the other examples. Please give it a try and let me know if there is any question.

[antweiss]

hi @alabulei1 ! can confirm the demos for both say hello and regex work. thanks a lot!

[katopz]

Hi @antweiss

Thanks for your feedback. It seems the demo web page has a stale ID for the deployed function. I followed the tutorial to build and deployed a new function and it worked. We will update the demo page soon.

azureuser@vivian2021:~/wasm-learning/faas/hello$ curl --location --request POST 'https://rpc.ssvm.secondstate.io:8081/api/run/475/say' \
> --header 'Content-Type: text/plain' \
> --data-raw 'Second State FaaS'
hello Second State FaaS

What causing stale id btw? I did try hello world example in Aug and now it's hit same error so it seem like it's not there forever and can be stale from unknown condition?

curl --location --request POST 'https://rpc.ssvm.secondstate.io:8081/api/run/423/say' \
--header 'Content-Type: text/plain' \
--data-raw 'Second State FaaS'

How can i prevent this? I can't find the docs mention about stale or expire.

[tpmccallum]

Hi @katopz I can answer this for you and provide some additional info as well.

Firstly, please check out the following URL which is the real-time log files from the FaaS server

http://rpc.ssvm.secondstate.io:9001/

Please note it is http not https. I sometimes use a different browser or incognito session so that the browser does not automatically use https.

[alabulei1]

Hi @katopz ,

Besides the additional information that Tim provided, I also want to explain that it is difficult for us to maintain Second State Functions as a free yet production-ready cloud service. 😭 Currently, we are running Second State Functions as a demo service, which we could upgrade and restart from time to time. We have open-sourced all the code for Second State Functions and encourage users to set up their own servers.

[katopz]

Hi @katopz I can answer this for you and provide some additional info as well.

Firstly, please check out the following URL which is the real-time log files from the FaaS server

http://rpc.ssvm.secondstate.io:9001/

Please note it is http not https. I sometimes use a different browser or incognito session so that the browser does not automatically use https.

Thanks, that's url work only on incognito. I got...

3","storage_key":"7f4c738846eaa8379de758e65fb1c234"},"preopens":{"/":"/tmp"}}

Instantiating SSVM with AOT filename of: /media/nvme/aot/338531e0-4733-4d3e-b519-930f919df8c3.so which has a typeof: string

Instantiation success!

It is resolved that the JSON object is not empty, returning to function execution ...

Parameters len == 1

Executing function WITHOUT a callback...

[2021-12-29 17:21:11.956] [error] load library failed:/media/nvme/aot/338531e0-4733-4d3e-b519-930f919df8c3.so: undefined symbol: intrinsics

[2021-12-29 17:21:11.956] [error] loading failed: invalid path, Code: 0x20

[2021-12-29 17:21:11.956] [error]     File name: "/media/nvme/aot/338531e0-4733-4d3e-b519-930f919df8c3.so"

[tpmccallum]

From the logs it looks like there is difficulty finding the executable (this may have happened when the server was moved to a new home a few months back). This should never happen in a perfect world; it seems like a mismatch with the migrating of binary files over to new server. Apologies for any inconvenience.

There are two things you can do to resolve this.

I will provide 2 solutions below.

[tpmccallum]

1. You can recompile the Rust and deploy to a new wasm_id

Fetch code

git clone https://github.com/second-state/wasm-learning.git

Change to area you want to work with

cd wasm-learning/faas/hello

Compile fresh wasm file

rustwasmc build

Deploy to FaaS server

curl --location --request POST 'https://rpc.ssvm.secondstate.io:8081/api/executables' \
--header 'Content-Type: application/octet-stream' \
--header 'SSVM-Description: say hello' \
--data-binary '@pkg/hello_lib_bg.wasm'

This will return a JSON object. Take note of the SSVM_Admin_Key, because we use that in option 2

{"wasm_id":498,"wasm_sha256":"0x4c1dc9592520448bc24cf37e6851814d43619f62a0be72bda607af61799f1b26","SSVM_Usage_Key":"00000000-0000-0000-0000-000000000000","SSVM_Admin_Key":"3879ca65-d927-452c-890e-c2af293bf369"}

[katopz]

Hi @katopz ,

Besides the additional information that Tim provided, I also want to explain that it is difficult for us to maintain Second State Functions as a free yet production-ready cloud service. 😭 Currently, we are running Second State Functions as a demo service, which we could upgrade and restart from time to time. We have open-sourced all the code for Second State Functions and encourage users to set up their own servers.

I know the pain pretty well, I just think we need some mention or warning about any limitation in docs so developer can expect with would work or not 😊

[tpmccallum]

2. You can update/refresh the existing binary by using a PUT request to an already existing wasm_id

Note this does require that the user has the original SSVM_Admin_Key from when they first deployed the original wasm executable (as shown in my comment directly above)

Once the new rustwasmc build has created the new binary, the user can perform the update as follows.

curl --location --request PUT 'https://rpc.ssvm.secondstate.io:8081/api/update_wasm_binary/498' \
--header 'Content-Type: application/octet-stream' \
--header 'SSVM_Admin_Key: 3879ca65-d927-452c-890e-c2af293bf369' \
--data-binary '@pkg/hello_lib_bg.wasm'

The above PUT request will overwrite the wasm binary and also create a brand new Ahead Of Time (AOT) compiled binary which will solve that original message that we received i.e. load library failed

Hope this makes sense :)

[tpmccallum]

This update is actually a really cool feature i.e. hotswap the logic of a program in real-time.

From a security standpoint:

a) the update requires that the SSVM_Admin_Key is in the headers. Only the original creator knows this key

b) from an integrity standpoint the frontend can also be written to check the wasm_sha256 of the binary each time it calls the backend. Please see example below.

curl --location -g --request GET 'https://rpc.ssvm.secondstate.io:8081/api/executables/498?filterBy=[%22wasm_sha256%22]'

Notice how the checksum is the same as the checksum returned (above) when the original wasm binary was deployed to the FaaS? If the Rust is changed in anyway the checksum will be completely different.

{"wasm_sha256":"0x4c1dc9592520448bc24cf37e6851814d43619f62a0be72bda607af61799f1b26"}

This means that a front end can always be 100% sure that it is calling logic that it trusts. With this extra security step the application developer would update the logic and then make sure the front end is aware of the new checksum.