Giter VIP home page Giter VIP logo

js-client's Introduction

Fluence JS Client

npm

This is the Javascript client for the Fluence network. The main role of the JS client is to connect to the Fluence Network and allow you to integrate Aqua code into your application.

Installation

JS Client only supports the ESM format that means not every Node.js project can install it. You can read more here

  1. Install the client:

    npm i @fluencelabs/js-client
  2. Add the following lines at the beginning of your code:

    import { Fluence, randomKras } from "@fluencelabs/js-client";
    
    Fluence.connect(randomKras());

HTML page

Add a script tag with the JS Client module to your index.html. The easiest way to do this is using a CDN ( like JSDELIVR or UNPKG).

Here is an example using the JSDELIVR CDN:

<head>
  <title>Cool App</title>
  <script type="module">
    import {
      Fluence,
      randomKras,
    } from "https://cdn.jsdelivr.net/npm/@fluencelabs/js-client/dist/browser/index.min.js";

    Fluence.connect(randomKras());
  </script>
</head>

If you cannot or don't want to use a CDN, feel free to get the script directly from the npm package and host it yourself. You can find the script in the /dist/browser directory of the package. (Note: this option means that developers understand what they are doing and know how to serve this file from their own web server.)

Usage in an Application

Once you've added the client, you can compile Aqua and run it in your application. To compile Aqua, use Fluence CLI.

  1. Install the package:

    npm i -D @fluencelabs/cli
  2. Add a directory in your project for Aqua code, e.g., _aqua.

  3. Put *.aqua files in that directory.

  4. Add a directory for compiled Aqua files inside your sources. For example, if your app source is located in the src directory, you can create src/_aqua.

  5. To compile Aqua code once, run npx fluence aqua -i ./_aqua -o ./src/_aqua/. To watch the changes and to recompile on the fly, add the -w flag: npx fluence aqua -w -i ./_aqua -o ./src/_aqua/.

    Hint: it might be a good idea to add these scripts to your package.json file. For example, you project structure could look like this:

     ┣ _aqua
     ┃ ┗ demo.aqua
     ┣ src
     ┃ ┣ _aqua
     ┃ ┃ ┗ demo.ts
     ┃ ┗ index.ts
     ┣ package-lock.json
     ┣ package.json
     ┗ tsconfig.json
    

    Then, your package.json file should include the following lines:

    {
      ...
      "scripts": {
        ...
        "aqua:compile": "fluence aqua -i ./aqua/ -o ./src/_aqua",
        "aqua:watch": "fluence aqua -w -i ./aqua/ -o ./src/_aqua"
      },
      ...
    }
    
  6. Now you can import and call Aqua code from your application like this:

    import { getRelayTime } from "./_aqua/demo";
    
    async function buttonClick() {
      const time = await getRelayTime();
      alert("relay time: " + time);
    }

Debug

JS Client uses the debug library under the hood for logging. The log namespaces are structured on a per-component basis, following this structure:

fluence:<component>:trace
fluence:<component>:debug
fluence:<component>:error

Marine JS logs have a slightly different structure:

fluence:marine:<service id>:trace
fluence:marine:<service id>:debug
fluence:marine:<service id>:info
fluence:marine:<service id>:warn
fluence:marine:<service id>:error

Each level corresponds to a logging level in Marine JS.

Star (*) character can be used as a wildcard to enable logs for multiple components at once. For example, DEBUG=fluence:* will enable logs for all components. To exclude a component, use a minus sign before the component name. For example, DEBUG=fluence:*,-fluence:particle:*

Index of components:

  • particle: everything related to particle processing queue
  • aqua: infrastructure of aqua compiler support
  • connection: connection layer
  • marine: Marine JS logs

Enabling logs in Node.js

Enable logs by passing the environment variable DEBUG with the corresponding log level. For example:

DEBUG=fluence:* node --loader ts-node/esm ./src/index.ts

Enabling logs in the browser

To enable logs, set the localStorage.debug variable. For example:

localStorage.debug = "fluence:*";

NOTE

In Chromium-based web browsers (e.g. Brave, Chrome, and Electron), the JavaScript console will be default—only to show messages logged by debug if the "Verbose" log level is enabled.

Low level usage

JS client also has an API for low level interaction with AVM and Marine JS. It could be handy in advanced scenarios when a user fetches AIR dynamically or generates AIR without default Aqua compiler.

callAquaFunction Allows to call aqua function without schema.

registerService Gives an ability to register service without schema. Passed service could be

  • Plain object. In this case all function properties will be registered as AIR service functions.
  • Class instance. All class methods without inherited ones will be registered as AIR service functions.

Development

To hack on the Fluence JS Client itself, please refer to the development page.

Documentation

The starting point for all documentation related to Fluence is fluence.dev. We also have an active YouTube channel.

Support

Please, file an issue if you find a bug. You can also contact us at Discord or Telegram. We will do our best to resolve the issue ASAP.

Contributing

Any interested person is welcome to contribute to the project. Please, make sure you read and follow some basic rules.

License

All software code is copyright (c) Fluence Labs, Inc. under the Apache-2.0 license.

js-client's People

Contributors

akim-bow avatar boneyard93501 avatar coder11 avatar diemyst avatar fluencebot avatar folex avatar gurinderu avatar inversionspaces avatar justprosh avatar mikevoronov avatar mikhail-1e20 avatar monoid avatar nahsi avatar renovate[bot] avatar shamsartem avatar valeryantopol avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar

js-client's Issues

Export PeerStatus from index.ts

We have Fluence.getStatus that returns PeerStatus, but PeerStatus itself isn't exported.

getStatus: () => import("./internal/FluencePeer").PeerStatus;

Throw error if a user tries to call a function with non-initialized peer

If a user tries execute a particle on non-initiated peer the execution will hang silently. Some examples on when it happens:

  1. A user forgets to pass the FluencePeer and doesn't have default peer initialized
  2. A user just forgets to initialize the default peer
  3. A user passes uninitialized FluencePeer

A good user-friendly error message should be thrown instead according to the current peer status

Deprecate and remove 'fromEd25519SK' method from KeyPair

KeyPair shouldn't be responsible for bytes format: it could be base64, base58, base123, zip, or whatever. KeyPair already accepts Uint8Array in fromBytes and that's enough.

However, the name fromEd25519SK is very appealing so I think it's best to remove it ASAP to avoid more and more people depending on it.

Implement Signing Service

Signing service is a built-it service, implemented in TS which allows to

  • sign byte data using peer's SK
  • verifying signatures using signed data and peer's peerID

Integrate asynchronous Aqua VM

Asynchronous version of Aqua VM is currently in development. It should be integrated into JS SDK.

Below is the description of the changes in AVM (copy-pasted here)

Guys, after fluencelabs/aquavm#130 the interpreter'll become async. It means that instead of sync waiting for a result in a call_service now the interpreter receives results in invoke export function.

The signature of call_serivce now looks as follows:

call_service(service_id: &str, fn_name: &str, args: &str, tetraplets: &str, call_id: u32)

The change here is an additional last parameter and no return results. This parameter represents id of call and should be used by host (node/client) later then to supply results into the interpreter while calling its invoke that now looks like this:

invoke(init_peer_id: String, air: String, prev_data: Vec<u8>, data: Vec<u8>, call_results: Vec<u8>) -> InterpreterOutcome

All is the same except an additional argument that should contain json-serialized HashMap<u32, CallServiceResult> . CallServiceResult is unchanged:

pub struct CallServiceResult {
    pub ret_code: i32,
    pub result: String,
}

After this PR a host behaviour should be changed also, now the interpreter could be called several times for each new current_data. Let's denote each such call as execution step. And the whole execution is completed if there were no call_service calls. More precisely, the interpreter flow inside a host could look in the following way:

  1. for each new current_data received from a network, host should call invoke with corresponding prev_data and current_data and empty call_results
  2. for each call_service a host should manage to match supplied call_id and computed service result. This computation could be either async or sync, it doesn't affect an interpreter (but affects resource consumption).
  3. after finishing execution step, there could be non-empty next_peer_ids and it's a node duty to decide should it send particle after each interpreter call or after the its whole execution. But please note that host still must preserve new_data after each execution step.
  4. If there were some call_service calls on step 2, a host must call the interpreter again with supplied call results (HashMap<u32, CallServiceResult>). Note, that current_data here shouldn't be supplied (actually, it could be supplied, but it's unnecessary and slow down a bit an interpreter execution). Then this flow should be repeated starting from point 2.
  5. If there were no call_service calls step, the whole execution is completed, new_data must be preserved and particle send for new_peer_pks as usual.

Support particle signatures

All particles must be signed by the initial peer (init_peer_id field).

Currently a field for particle signature exists but is not used.

#108 should be taken into consideration when implementing this feature.

Logs: introduce network-monitoring logs to INFO level

Right now, the most useful log level for debugging is 'debug'. However, it is way too verbose for particle monitoring: it shows AIR script every time, all prevData and `data. I think that's OK for debug, at least for now.

But often I want to see particles coming in and out, and service-functions being called. I think 'info' level could be used for that role.

I suggest to show the following logs in the info:

  • particle $particleId sent
  • particle $particleId received
  • $serviceId $function called with $args

All $var should be replaced with values, e.g. $particleId with uuid of the particle, and so on.

I assume that errors like $aquaFunction timeouts are reported to WARN or ERROR levels, so they should be visible with setLogLevel('info') as well.

This log should stay in 'debug':

particle 7e820e44-4390-4d58-a601-aff2e69dafcb has expired after 7000. Deleting particle-related queues and handlers

Show human-readable error if avmRunner scripts are not available

Right now, if user haven't run npx run copy-avm-public, then he will receive and undecipherable error message from browser engine:
telegram-cloud-photo-size-2-5328219510274111844-x
telegram-cloud-photo-size-2-5328219510274111852-y

We must give users human-readable errors that suggest how to fix the problem. Ideally, we need to either catch this error or check avmRunner scripts availability proactively, and then show message suggesting to run copy-avm-public.

Move 'waiting for an argument ...' to DEBUG logs

Right now, these messages look like errors and do not explain anything. Only confuse people.

In any case, they're needed for debugging purposes, so I suggest to move these logs under DEBUG log level.

Another approach, though a hard one, may be to hide these logs altogether and print out in case of a timeout error.

telegram-cloud-photo-size-2-5334755866383071823-x

peer contact should work on while particle on client

func describe_neighborhood(initial_relay:PeerId) -> *Contact:
    contacts: *Contact
    contacts <- Peer.get_contact(initial_relay)
{
  error: `Local service error: ret_code is 1024, error message is '"The handler did not set any result. Make sure you are calling the right peer and the handler has been registered. Original request data was: serviceId='peer' fnName='get_contact' args='12D3KooWAPryc7ZKpbPPhEdHjLiHZYzHGYPkQGBwE77R2eRLMUtQ'"'`,
  instruction: 'call %init_peer_id% ("peer" "get_contact") [initial_relay] &$contacts'
}

because i am peer

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Rate-Limited

These updates are currently rate-limited. Click on a checkbox below to force their creation now.

  • chore(deps): update dependency @libp2p/crypto to v4.0.4
  • chore(deps): update dependency @libp2p/interface to v1.1.5
  • chore(deps): update dependency @libp2p/peer-id to v4.0.8
  • chore(deps): update dependency @libp2p/peer-id-factory to v4.0.8
  • chore(deps): update dependency @libp2p/ping to v1.0.13
  • chore(deps): update dependency @libp2p/utils to v5.2.7
  • chore(deps): update dependency @libp2p/websockets to v8.0.17
  • chore(deps): update dependency @types/node to v16.18.91
  • chore(deps): update dependency it-length-prefixed to v9.0.4
  • chore(deps): update dependency js-base64 to v3.7.7
  • chore(deps): update dependency multiformats to v11.0.2
  • chore(deps): update dependency ts-pattern to v5.0.8
  • chore(deps): update dependency uint8arrays to v4.0.10
  • chore(deps): update all github-actions (hashicorp/vault-action, pnpm/action-setup)
  • chore(deps): update dependency @chainsafe/libp2p-noise to v14.1.0
  • chore(deps): update dependency @multiformats/multiaddr to v12.2.1
  • chore(deps): update dependency @npmcli/arborist to ^7.3.0
  • chore(deps): update dependency @testing-library/jest-dom to v5.17.0
  • chore(deps): update dependency libp2p to v1.3.1
  • chore(deps): update dependency rxjs to v7.8.1
  • chore(deps): update react monorepo (@types/react, @types/react-dom)
  • chore(deps): update all github-actions (major) (actions/checkout, actions/setup-node, docker/login-action, google-github-actions/release-please-action, hashicorp/vault-action, pnpm/action-setup, stefanzweifel/git-auto-commit-action)
  • chore(deps): update dependency @chainsafe/libp2p-noise to v15
  • chore(deps): update dependency @testing-library/jest-dom to v6
  • chore(deps): update dependency @testing-library/react to v14
  • chore(deps): update dependency @testing-library/user-event to v14
  • chore(deps): update dependency @types/jest to v29
  • chore(deps): update dependency multiformats to v13
  • chore(deps): update dependency uint8arrays to v5
  • chore(deps): update dependency uuid to v9 (uuid, @types/uuid)
  • chore(deps): update dependency web-vitals to v3
  • chore(deps): update dependency @rollup/plugin-inject to v5.0.5
  • chore(deps): update dependency @tsconfig/strictest to v2.0.5
  • chore(deps): update dependency @types/bs58 to v4.0.4
  • chore(deps): update dependency @types/debug to v4.1.12
  • chore(deps): update dependency @types/serve-handler to v6.1.4
  • chore(deps): update dependency @types/treeverse to v3.0.5
  • chore(deps): update dependency @types/uuid to v8.3.4
  • chore(deps): update dependency eslint-plugin-license-header to v0.6.1
  • chore(deps): update dependency ts-node to v10.9.2
  • chore(deps): update dependency @types/node to v18.19.26
  • chore(deps): update dependency esbuild to v0.20.2
  • chore(deps): update dependency eslint to v8.57.0
  • chore(deps): update dependency eslint-config-prettier to v9.1.0
  • chore(deps): update dependency eslint-plugin-import to v2.29.1
  • chore(deps): update dependency eslint-plugin-unused-imports to v3.1.0
  • chore(deps): update dependency prettier to v3.2.5
  • chore(deps): update dependency puppeteer to v19.11.1
  • chore(deps): update dependency typescript to v5.4.3
  • chore(deps): update dependency vite to v4.5.3
  • chore(deps): update dependency vite-tsconfig-paths to v4.3.2
  • chore(deps): update typescript-eslint monorepo to v6.21.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
  • chore(deps): update dependency @types/node to v20.11.30
  • chore(deps): update dependency puppeteer to v22
  • chore(deps): update dependency vite to v5
  • chore(deps): update dependency vitest to v1
  • chore(deps): update typescript-eslint monorepo to v7 (major) (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
  • 🔐 Create all rate-limited PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

Detected dependencies

github-actions
.github/workflows/e2e.yml
.github/workflows/lint.yml
  • amannn/action-semantic-pull-request v5
  • actions/checkout v3
  • reviewdog/action-actionlint v1
.github/workflows/release.yml
  • google-github-actions/release-please-action v3
  • actions/checkout v3
  • pnpm/action-setup v2.2.4
  • actions/setup-node v3
  • stefanzweifel/git-auto-commit-action v4
  • actions/checkout v3
  • hashicorp/vault-action v2.4.3
  • pnpm/action-setup v2.2.4
  • actions/setup-node v3
  • lwhiteley/dependent-jobs-result-check v1
  • hashicorp/vault-action v2.4.3
  • ravsamhq/notify-slack-action v2
.github/workflows/snapshot.yml
  • actions/checkout v3
  • pnpm/action-setup v2.2.4
  • actions/setup-node v3
  • hashicorp/vault-action v2.4.3
.github/workflows/tests.yml
  • hashicorp/vault-action v2.4.3
  • docker/login-action v2
  • actions/checkout v3
  • fluencelabs/setup-fluence v1
  • pnpm/action-setup v2.2.4
  • actions/setup-node v3
  • jwalton/gh-docker-logs v2
npm
package.json
  • @total-typescript/ts-reset 0.5.1
  • @tsconfig/strictest 2.0.2
  • @types/node 18.13.0
  • @typescript-eslint/eslint-plugin 6.7.3
  • @typescript-eslint/parser 6.7.3
  • eslint 8.50.0
  • eslint-config-prettier 9.0.0
  • eslint-plugin-import 2.28.1
  • eslint-plugin-license-header 0.6.0
  • eslint-plugin-unused-imports 3.0.0
  • http-server 14.1.1
  • prettier 3.0.3
  • puppeteer 19.7.2
  • ts-node 10.9.1
  • typescript 5.1.6
  • node >=10
  • pnpm >=3
packages/@tests/aqua/package.json
  • base64-js 1.5.1
  • @fluencelabs/aqua-api 0.13.0
  • @fluencelabs/aqua-lib 0.6.0
  • @fluencelabs/registry 0.9.0
  • @fluencelabs/trust-graph 3.1.2
  • ts-node 10.9.1
  • node >=10
  • pnpm >=3
packages/@tests/smoke/node/package.json
  • node >=10
  • pnpm >=3
packages/@tests/smoke/web-cra-ts/package.json
  • @testing-library/jest-dom 5.16.5
  • @testing-library/react 13.4.0
  • @testing-library/user-event 13.5.0
  • @types/jest 27.5.2
  • @types/node 16.18.12
  • @types/react 18.0.27
  • @types/react-dom 18.0.10
  • react ^18.2.0
  • react-dom ^18.2.0
  • react-scripts 5.0.1
  • web-vitals 2.1.4
  • puppeteer 19.7.2
packages/@tests/smoke/web/package.json
  • puppeteer 19.7.2
  • node >=10
  • pnpm >=3
packages/@tests/test-utils/package.json
  • serve-handler 6.1.5
  • @types/serve-handler 6.1.1
  • node >=10
  • pnpm >=3
packages/core/aqua-to-js/package.json
  • ts-pattern 5.0.5
  • @fluencelabs/aqua-api 0.13.0
  • @fluencelabs/aqua-lib 0.7.3
  • @fluencelabs/registry 0.9.0
  • @fluencelabs/spell 0.5.20
  • @fluencelabs/trust-graph 0.4.7
  • vitest 0.34.6
  • zod 3.22.4
packages/core/fluence-network-environment/package.json
packages/core/interfaces/package.json
  • hotscript 1.0.13
  • node >=10
  • pnpm >=3
packages/core/js-client-isomorphic/package.json
  • @fluencelabs/avm 0.62.0
  • @fluencelabs/marine-js 0.13.0
  • @fluencelabs/marine-worker 0.6.0
  • @fluencelabs/threads ^2.0.0
packages/core/js-client/package.json
  • @chainsafe/libp2p-noise 14.0.0
  • @chainsafe/libp2p-yamux 6.0.1
  • @fluencelabs/avm 0.62.0
  • @fluencelabs/marine-worker 0.6.0
  • @fluencelabs/threads ^2.0.0
  • @libp2p/crypto 4.0.1
  • @libp2p/identify 1.0.11
  • @libp2p/interface 1.1.2
  • @libp2p/peer-id 4.0.5
  • @libp2p/peer-id-factory 4.0.5
  • @libp2p/ping 1.0.10
  • @libp2p/utils 5.2.2
  • @libp2p/websockets 8.0.12
  • @multiformats/multiaddr 12.1.12
  • bs58 5.0.0
  • debug 4.3.4
  • int64-buffer 1.0.1
  • it-length-prefixed 9.0.3
  • it-map 3.0.5
  • it-pipe 3.0.1
  • js-base64 3.7.5
  • libp2p 1.2.0
  • multiformats 11.0.1
  • rxjs 7.5.5
  • uint8arrays 4.0.3
  • uuid 8.3.2
  • zod 3.22.4
  • @fluencelabs/aqua-api 0.13.0
  • @rollup/plugin-inject 5.0.5
  • @types/bs58 4.0.1
  • @types/debug 4.1.7
  • @types/node 20.7.0
  • @types/uuid 8.3.2
  • esbuild 0.19.5
  • hotscript 1.0.13
  • vite 4.4.11
  • vite-tsconfig-paths 4.0.3
  • vitest 0.34.6
  • node >=10
  • pnpm >=8
packages/core/marine-worker/package.json
  • @fluencelabs/marine-js 0.13.0
  • observable-fns 0.6.1
  • @fluencelabs/threads ^2.0.0
  • @rollup/plugin-inject 5.0.3
  • @types/node 20.4.5
  • node-stdlib-browser 1.2.0
  • vite 4.4.11
  • vitest 0.34.6
packages/core/npm-aqua-compiler/package.json
  • @npmcli/arborist ^7.2.1
  • treeverse 3.0.0
  • @types/npmcli__arborist 5.6.5
  • @types/treeverse 3.0.4
  • vitest 0.34.6

  • Check this box to trigger a request for Renovate to run again on this repository

Run Aqua VM in background

Aqua VM interpreter runs on the main thread. It may cause performance problems noticeable to browser users. An incoming particle can potentially block the entire application UI and there is no mechanism to prevent that.

There should be an option to run particles' script interpretation in a separate thread using webworkers in browser and worker threads in nodejs.

The implementation should consider the following:

  1. The execution strategy should be configurable
  2. Both nodejs and browser should be supported with no difference to JS SDK consumers
  3. The code should be reused between nodejs and browsers as possible

This issue depends on the integration of the async AVM #73

Error reporting: show particleId when Aqua function fails

Right now, when Aqua function times out or fails, the error could look like this

initTopicAndSubscribeBlocking failed Request timed out for initTopicAndSubscribeBlocking

It's not giving enough info to debug the issue on local node, or anywhere.

I think printing particleId and maybe relayId would improve debug possibilities a lot.

Test for linear

Just trying to test if the issue will be imported automatically

Handle network outages correctly

FluencePeer should seamlessly handle low and no connectivity situations. Including

  1. The peer should continue to operate if the networks connections is down (particles should not be lost)
  2. When the network is up again all non-expired particles should be correctly sent to the network
  3. Transparent network status notifications to API consumers
  4. Method for manual connection management (disconnect, reconnect, etc)
  5. Transparent connection lifecycle statuses

Support connection to multiple relays

It would be nice to have the ability to connect to multiple relays because it could increase the applications reliability.

Research topics:

How to handle multiple connections at once?
Is it possible to accept new incoming connections?
Should the single peer id be shared among multiple connections?
What is the best architecture for connection pooling?
How particles routing should work?
What changes to the public API are necessary?

Wait in Fluence.stop() for pending particles

Pending particles skipped on process exit if there is no return result.

Example to reproduce:
export.aqua:

module Export

export GreetingService, greeting

service GreetingService("greeting"):
    identity(name: string) -> string

func greeting(peer_id: string, relay_id: string):
    on peer_id via relay_id:
        GreetingService.identity("message")

server.ts:

import { registerGreetingService } from "./generated/export"
import { krasnodar } from "@fluencelabs/fluence-network-environment"
import { Fluence } from "@fluencelabs/fluence"

async function main() {
    await Fluence.start({connectTo: krasnodar[0]});
    console.log(Fluence.getStatus().peerId, Fluence.getStatus().relayPeerId);

    await registerGreetingService({
        identity: (name) => {
            console.log("Message received:", name);
            return "Hi, " + name;
        }
    })

    process.stdin.setRawMode(true);
    process.stdin.resume();
    process.stdin.on('data', async () => {
        await Fluence.stop();
        process.exit(0);
    });
}

main().catch((err) => console.error(err));

client.ts:

import { greeting } from "./generated/export"
import { krasnodar } from "@fluencelabs/fluence-network-environment"
import { Fluence } from "@fluencelabs/fluence"


async function main(peer_id: string, relay_id: string) {
    await Fluence.start({connectTo: krasnodar[2]});
    await greeting(peer_id, relay_id);
}

let peer_id = process.argv[2];
let relay_id = process.argv[3];
main(peer_id, relay_id).catch((err) => console.error(err));

If client.ts has an active wait or greeting has a return result, server will receive the message

So this issue is connected with an early exit from the process without processing pending particles.

Passing undefined value to `withVariables` causes an unhandled exception

new RequestFlowBuilder()
  .withRawScript('(null)')
  .withVariables(new Map([["a", undefined]]))

When such a flow is passed to initiateFlow, a crash happens:

(node:51371) UnhandledPromiseRejectionWarning: RuntimeError: unreachable
    at null.<anonymous> (wasm://wasm/002a80f2:0:624631)
    at null.<anonymous> (wasm://wasm/002a80f2:0:628035)
    at null.<anonymous> (wasm://wasm/002a80f2:0:627655)
    at null.<anonymous> (wasm://wasm/002a80f2:0:627971)
    at null.<anonymous> (wasm://wasm/002a80f2:0:620577)
    at null.<anonymous> (wasm://wasm/002a80f2:0:90358)
    at null.<anonymous> (wasm://wasm/002a80f2:0:96561)
    at null.<anonymous> (wasm://wasm/002a80f2:0:102404)
    at null.<anonymous> (wasm://wasm/002a80f2:0:105035)
    at null.<anonymous> (wasm://wasm/002a80f2:0:102429)

failures of particles should not look like hangs

  1. send invalid particle. await result.observe timeout.
  2. turn old logs. observe:
Interpreter result:  {
  retCode: 0,
  errorMessage: "air can't be parsed:\n" +
    'error: \n' +
    '    ┌─ script.air:311:45\n' +
    '    │\n' +
    '311 │                                             (ap $records.$.[0]! $awaiter)\n' +

expected: await should be rejected and throw exception asap in case of failed particle

Add `debug stringify` service

Add "debug" "stringify" T -> string service into builtins to make it possible to convert any variable into string for debugging purposes.

Crypric error when trying to use HOST_PEER_ID in non-connected peer

Aqua code:

--- hello-world.aqua
import "@fluencelabs/aqua-lib/builtin.aqua"

func getRelayTimestamp() -> u64:
    on HOST_PEER_ID:
        ts <- Peer.timestamp_ms()
    <- ts

Typescript code:

import { Fluence } from '@fluencelabs/fluence';
import { getRelayTimestamp } from './_aqua/hello-world';

async function main() {
    await Fluence.start();

    const timestamp = await getRelayTimestamp();
    console.log(new Date(timestamp));

    await Fluence.stop();
}

main().catch((err) => console.error(err));

Actual error:

{
  error_code: 10002,
  instruction: 'call -relay- ("peer" "timestamp_ms") [] ts',
  message: "expected JValue type 'string' for the variable `-relay-`, but got 'null'",
  peer_id: '12D3KooWFiUHqEcr8HYzwec2sU6XThQ1rS1aKh3bKcUbsEDW3DYz'
}

Excepted: "The peer is not connected to the relat". Or something along those lines

Catch protocol selection error and suggest user to update JS SDK

Currently, if a node changes its protocol name, JS SDK throws the following error:

Error on sending particle with id c5be9a50-f4a4-48f5-8adb-0bbcb7d349d7: Error: protocol selection failed
eval @ RequestFlow.js:177

Instead, it should suggest a user updating JS SDK.

How to reproduce the error

Change PROTOCOL_NAME and connect to any node

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.