Merge did:indy support

[andrewwhitehead]

Currently, tests are failing with the JS wrapper due to a timeout in GetAttribRequest. I think this might be a compatibility issue with the did:indy-supporting indy-node version, but I'm not certain.

[swcurran]

Who can/should look at this? @blu3beri — is that something you can look at?

@andrewwhitehead — any details that would help — any details on how to reproduce, what is happening/where?

[andrewwhitehead]

There are more details in the CI logs, specifically

FAIL tests/GetAttribRequest.test.ts (120.218 s)
  GetAttribRequest
    ✕ Submit request (120001 ms)

  ● GetAttribRequest › Submit request

    thrown: "Exceeded timeout of 120000 ms for a test.
    Use jest.setTimeout(newTimeout) to increase the timeout value, if this is a long-running test."

      10 |   beforeAll(() => (pool = setupPool()))
      11 |
    > 12 |   test('Submit request', async () => {
         |   ^
      13 |     const request = new GetAttribRequest({ targetDid: DID, raw: 'endpoint' })
      14 |     const response: GetAttribResponse = await pool.submitRequest(request)
      15 |

      at tests/GetAttribRequest.test.ts:12:3
      at Object.<anonymous> (tests/GetAttribRequest.test.ts:7:1)

But there also seems to be a segfault after the tests complete (could be related to the Python test shutdown issue where it needs to stop the tokio threads first, or could be the additional parameters to the indy_vdr_build_nym_request FFI method).

[c2bo]

This still has a custom old build of indy-node in it (from here: https://github.com/domwoe/indy-node/tree/feature/did-indy-new). Should we test #112 on this branch and figure out if this fixes things?

[c2bo]

Hmm, I tried testing this locally with the current and updated docker image and it seems to have no impact (both times the GetAttribRequest timeouts). Interesting is that I see another test failing:

 FAIL  tests/GetNymRequest.test.ts
  ● GetNymRequest › Submit request

    Invalid pointer for result value

      14 |   const indyVdrErrorObject = JSON.parse(nativeError.deref() as string) as IndyVdrErrorObject
      15 |
    > 16 |   throw new IndyVdrError(indyVdrErrorObject)
         |         ^
      17 | }
      18 |

      at handleError (src/error.ts:16:9)
      at NodeJSIndyVdr.buildGetNymRequest (src/NodeJSIndyVdr.ts:267:5)
      at new buildGetNymRequest (../indy-vdr-shared/src/builder/GetNymRequest.ts:28:28)
      at _callee$ (tests/GetNymRequest.test.ts:13:21)
      at tryCatch (../node_modules/regenerator-runtime/runtime.js:63:40)
      at Generator.invoke [as _invoke] (../node_modules/regenerator-runtime/runtime.js:294:22)
      at Generator.next (../node_modules/regenerator-runtime/runtime.js:119:21)
      at tryCatch (../node_modules/regenerator-runtime/runtime.js:63:40)
      at invoke (../node_modules/regenerator-runtime/runtime.js:155:20)
      at ../node_modules/regenerator-runtime/runtime.js:190:11

[c2bo]

Nevermind - the typescript tests are running with the sovrin buildernet instead of the local pool setup?
The libindy_vdr header (in libindy_vdr/include) file seems to be the old one before the changes - shouldn't this always create problems with a changed interface (for attrib and nym that added timestamp/version to the calls)?

#167 Should be a quick fix to get things running again (only fixes the parameters for the ffi calls - does not add the functionality properly to the javascript library).

[andrewwhitehead]

@c2bo Not sure if the separate did-indy-pool.dockerfile is still needed or we can just use indy-node-container 1.13.2-rc5 for all tests?

[c2bo]

@c2bo Not sure if the separate did-indy-pool.dockerfile is still needed or we can just use indy-node-container 1.13.2-rc5 for all tests?

We don't need the separate dockerifle anymore as far as i know -> That would be fixed by #112. I will re-base to this branch and create a new PR

[TimoGlastra]

We'll try to update the js wrapper to use the local pool instead!

[c2bo]

I added a small bash script in #169 that we can use for the different tests that want to use a local node pool. I just realized the same is true for the python wrapper - that one currently uses the idunion test network for its tests

./test.sh up
./test.sh down

[berendsliedrecht]

Couple small items, nothing blocking.

[swcurran]

w00t!!!