Wrap error structure #1431

krisbitney · 2022-11-21T14:01:55Z

This PR adds a custom WrapError error structure that is capable of parsing errors from strings, allowing us to improve error formatting and provide additional information for debugging.

Example error output for URI Resolution Exception:

    WrapError: SubInvocation exception encountered
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://fs//Users/kris/WebstormProjects/monorepo/packages/test-cases/cases/wrappers/wasm-as/subinvoke-error/invoke/build
    method: subWrapperNotFound
    args: {
      "a": 1,
      "b": 1
    } 
    source: { file: "~lib/@polywrap/wasm-as/containers/Result.ts", row: 171, col: 13 }
    
    Another exception was encountered during execution:
    WrapError: Unable to find URI wrap://ens/not-found.eth.
    code: 27 URI NOT FOUND
    uri: wrap://ens/not-found.eth
    uriResolutionStack: [
      "wrap://ens/not-found.eth => PackageToWrapperCacheResolver",
      [
        "wrap://ens/not-found.eth => UriResolverAggregator",
        [
          "wrap://ens/not-found.eth => StaticResolver - Miss",
          "wrap://ens/not-found.eth => ExtendableUriResolver",
          [
            "wrap://ens/ipfs-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/ipfs-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/ipfs-resolver.polywrap.eth)",
            "wrap://ens/ens-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/ens-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/ens-resolver.polywrap.eth)",
            "wrap://ens/fs-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/fs-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/fs-resolver.polywrap.eth)",
            "wrap://ens/http-resolver.polywrap.eth => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ens/http-resolver.polywrap.eth)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ens/http-resolver.polywrap.eth)",
            "wrap://ipfs/QmfRCVA1MSAjUbrXXjya4xA9QHkbWeiKRsT7Um1cvrR7FY => PackageToWrapperCacheResolver (Cache) => wrapper (wrap://ipfs/QmfRCVA1MSAjUbrXXjya4xA9QHkbWeiKRsT7Um1cvrR7FY)",
            "wrap://ens/not-found.eth => ResolverExtension (wrap://ipfs/QmfRCVA1MSAjUbrXXjya4xA9QHkbWeiKRsT7Um1cvrR7FY)"
          ]
        ]
      ]
    ]

Example error output for exception thrown during Wasm invocation:

    WrapError: SubInvocation exception encountered
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://fs//Users/kris/WebstormProjects/monorepo/packages/test-cases/cases/wrappers/wasm-as/subinvoke-error/invoke/build
    method: throwsInTwoSubinvokeLayers
    args: {
      "a": 1,
      "b": 1
    } 
    source: { file: "~lib/@polywrap/wasm-as/containers/Result.ts", row: 171, col: 13 }
    
    Another exception was encountered during execution:
    WrapError: SubInvocation exception encountered
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://ens/bad-math.eth
    method: subInvokeWillThrow
    args: {
      "0": 130,
      "1": 161,
      "2": 97,
      "3": 1,
      "4": 161,
      "5": 98,
      "6": 1
    } 
    source: { file: "~lib/@polywrap/wasm-as/containers/Result.ts", row: 171, col: 13 }
    
    Another exception was encountered during execution:
    WrapError: __wrap_abort: I threw an error!
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://ens/bad-util.eth
    method: iThrow
    args: {
      "0": 129,
      "1": 161,
      "2": 97,
      "3": 0
    } 
    source: { file: "src/index.ts", row: 5, col: 5 }

Example error output for exception thrown during plugin wrapper invocation:

    WrapError: I'm throwing!
    code: 50 WRAPPER INVOKE ABORTED
    uri: wrap://plugin/mock
    method: methodThatThrows
    args: {} 
    source: { file: "/Users/kris/WebstormProjects/monorepo/packages/js/client/src/__tests__/helpers/mockPluginRegistration.ts", row: 13, col: 17 }

Closes #701

packages/js/core/src/types/WrapError.ts

…cture # Conflicts: # packages/js/client/src/PolywrapClient.ts

…ts for wrap error structure

…error-structure

packages/js/core/src/types/WrapError.ts

…apError

packages/js/client/package.json

packages/js/core/src/types/WrapError.ts

packages/js/wasm/src/imports.ts

packages/js/core/src/types/WrapError.ts

… code analysis

dOrgJelli · 2023-01-03T21:05:47Z

🔥 🔥 🔥 🔥 🔥 🔥

packages/js/wasm/src/WasmWrapper.ts

packages/js/core/src/types/WrapError.ts

nerfZael · 2023-01-03T22:52:41Z

packages/js/core/src/types/WrapError.ts

+  100-255 -> Unallocated
+ */
+export enum WrapErrorCode {
+  UNKNOWN,


In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.

Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

nerfZael · 2023-01-03T22:58:14Z

packages/js/core/src/types/WrapError.ts

+    Object.setPrototypeOf(this, WrapError.prototype);
+  }
+
+  static parse(error: string): WrapError | undefined {


There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).

The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.

The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.

The parsing logic here is both of those things.

packages/js/core/src/types/WrapError.ts

krisbitney · 2023-01-04T05:26:01Z

@nerfZael

Somehow I can't reply to some of your messages so I'm responding here.

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.

Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

I removed UNKNOWN and am starting the enum at 1.

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).

The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.
The parsing logic here is both of those things.

All errors from Wasm modules are made to be of type WrapError.

It is possible that a message is not a stringified WrapError, but still we need to check whether it is or not (I explain why in your other question about parse). The parse method returns undefined when a message is not a WrapError, in which case message is used as the error message in a new WrapError.

…ault code value; the `prev` property in WrapError was renamed to `innerError`; changed type of innerError to WrapError

packages/js/wasm/src/WasmWrapper.ts

packages/js/core/src/types/WrapError.ts

nerfZael · 2023-01-04T19:48:21Z

@nerfZael

Somehow I can't reply to some of your messages so I'm responding here.

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.
Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

I removed UNKNOWN and am starting the enum at 1.

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).
The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.
The parsing logic here is both of those things.

All errors from Wasm modules are made to be of type WrapError.

It is possible that a message is not a stringified WrapError, but still we need to check whether it is or not (I explain why in your other question about parse). The parse method returns undefined when a message is not a WrapError, in which case message is used as the error message in a new WrapError.

We can address this in a followup PR when we use msgpack for error serialization

…or internal errors

…rror"

krisbitney · 2023-01-05T06:28:24Z

@nerfZael
Somehow I can't reply to some of your messages so I'm responding here.

In cases where we're reading from a buffer, and we get a zero there, I think the buffer should be treated as corrupted and not a valid WrapError. I do not think we should be allowing undefined states for an enum we control. The error codes, IMO, should start at 1.
Still, I am fine with keeping this for the time being and being more strict about the codes in the future.

I removed UNKNOWN and am starting the enum at 1.

There's 2 things one can parse: serialized WrapErrors and errors from wasm modules (which may or may not be WrapErrors).
The serialized WrapError parsing logic should be in the WrapError, or somewhere close. It is easy to parse since we know the structure and does not need regex.
The wasm module error parsing logic should be in wasm-js. And since it can be anything regex is fine there.
The parsing logic here is both of those things.

All errors from Wasm modules are made to be of type WrapError.
It is possible that a message is not a stringified WrapError, but still we need to check whether it is or not (I explain why in your other question about parse). The parse method returns undefined when a message is not a WrapError, in which case message is used as the error message in a new WrapError.

We can address this in a followup PR when we use msgpack for error serialization

Okay, sounds good.

nerfZael

LGTM!

krisbitney added 8 commits November 14, 2022 19:33

added tests for invoke error structure

270612f

added InvokeError and error structure tests

be51143

uncommented some lines in error-structure.spec.ts

3dd3d17

moved InvokeError to core-js

d5f8b85

custom error structure prints correct output

f4993e4

added test for incompatible wasm wrapper version

b8399cf

removed unnecessary files from deprecated wrapper test case

add1436

added more info to comment in WrapError.ts

b5db3f2

github-advanced-security bot found potential problems Nov 21, 2022

View reviewed changes

krisbitney added 6 commits December 5, 2022 22:43

Merge remote-tracking branch 'origin/origin-dev' into wrap-error-stru…

f04efd5

…cture # Conflicts: # packages/js/client/src/PolywrapClient.ts

moved wrap error structure updates to core client

908fa7b

improved tests for wrap error structure

97d4ceb

added WrapError to more modules, added more error codes, improved tes…

4fa295d

…ts for wrap error structure

Merge remote-tracking branch 'origin/wrap-error-structure' into wrap-…

b314981

…error-structure

fixed WrapError parsing for multi-error stacks

beeb967

github-advanced-security bot found potential problems Dec 8, 2022

View reviewed changes

packages/js/core/src/types/WrapError.ts Fixed Show fixed Hide fixed

krisbitney added 5 commits December 8, 2022 20:26

initial wrap error structure tests passing

9db1636

added try-catch block to PluginModule method invocation

a201bd6

fixed some plugin and client tests for WrapError

ba5c3dc

fixed more plugin and client tests for WrapError

bf7fb2a

added WASM_STATE_ERROR and WASM_SERIALIZATION_ERROR error codes to Wr…

743f239

…apError

krisbitney marked this pull request as ready for review December 10, 2022 05:15

krisbitney requested review from dOrgJelli, nerfZael, ramilexe, cbrzn, namesty and Niraj-Kamdar as code owners December 10, 2022 05:15

removed unnecessary number specified on WASM_SUBINVOKE_ABORTED

5566b13

dOrgJelli requested changes Dec 17, 2022

View reviewed changes

packages/js/client/package.json Outdated Show resolved Hide resolved

packages/js/core/src/types/WrapError.ts Outdated Show resolved Hide resolved

packages/js/core/src/types/WrapError.ts Show resolved Hide resolved

packages/js/wasm/src/imports.ts Outdated Show resolved Hide resolved

krisbitney added 3 commits December 29, 2022 20:30

added ".polywrap" to modulePathIgnorePatterns in jest config in client

d99fa44

fixed some paths in wrap error tests

a309411

removed unnecessary \r\n from WrapError regex

4f0c681

github-advanced-security bot found potential problems Dec 29, 2022

View reviewed changes

packages/js/core/src/types/WrapError.ts Fixed Show fixed Hide fixed

adjusted patterns in WrapError regex that were marked "suspicious" by…

1cde74f

… code analysis

polywrap deleted a comment from lgtm-com bot Dec 29, 2022

dOrgJelli previously approved these changes Jan 3, 2023

View reviewed changes

nerfZael requested changes Jan 3, 2023

View reviewed changes

wrap error codes now start at 1; abort in wasm-js no longer has a def…

bfab74f

…ault code value; the `prev` property in WrapError was renamed to `innerError`; changed type of innerError to WrapError

krisbitney dismissed dOrgJelli’s stale review via bfab74f January 4, 2023 05:58

nerfZael requested changes Jan 4, 2023

View reviewed changes

packages/js/wasm/src/WasmWrapper.ts Show resolved Hide resolved

packages/js/core/src/types/WrapError.ts Show resolved Hide resolved

krisbitney added 2 commits January 5, 2023 11:27

split abort into two methods, one for aborted invocations and one f…

ad89070

…or internal errors

fixed wrap error tests for name change of prop from "prev" to "innerE…

1a1b1cf

…rror"

nerfZael previously approved these changes Jan 5, 2023

View reviewed changes

dOrgJelli added 2 commits January 5, 2023 14:10

Merge branch 'origin-dev' into wrap-error-structure

dd2922f

fix: error test

4923540

dOrgJelli dismissed nerfZael’s stale review via 4923540 January 5, 2023 19:17

fix: error-structure tests

5995310

dOrgJelli approved these changes Jan 5, 2023

View reviewed changes

dOrgJelli merged commit 5d290ec into origin-dev Jan 5, 2023

krisbitney deleted the wrap-error-structure branch January 6, 2023 05:23

dOrgJelli mentioned this pull request Apr 14, 2023

Polywrap Origin (0.10.0) #1688

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Wrap error structure #1431

Wrap error structure #1431

krisbitney commented Nov 21, 2022 •

edited

Loading

dOrgJelli commented Jan 3, 2023

nerfZael Jan 3, 2023

nerfZael Jan 3, 2023

krisbitney commented Jan 4, 2023 •

edited

Loading

nerfZael commented Jan 4, 2023

krisbitney commented Jan 5, 2023

nerfZael left a comment

Wrap error structure #1431

Wrap error structure #1431

Conversation

krisbitney commented Nov 21, 2022 • edited Loading

dOrgJelli commented Jan 3, 2023

nerfZael Jan 3, 2023

Choose a reason for hiding this comment

nerfZael Jan 3, 2023

Choose a reason for hiding this comment

krisbitney commented Jan 4, 2023 • edited Loading

nerfZael commented Jan 4, 2023

krisbitney commented Jan 5, 2023

nerfZael left a comment

Choose a reason for hiding this comment

krisbitney commented Nov 21, 2022 •

edited

Loading

krisbitney commented Jan 4, 2023 •

edited

Loading