Accessing Vault after cloning fails

[tegefaulkes]

Describe the bug

During the process of creating the Agent-Agent interaction tutorial I found a bug. Right after cloning a vault from a remote agent the local agent would throw an error if you tried to access the newly cloned vault.

The error is as follows.

TypeError: Cannot read properties of undefined (reading 'isLocked')
    at VaultInternal.readF (/home/faulkes/matixWorkspace/gitRepos/Polykey/node_modules/@matrixai/async-init/src/CreateDestroyStartStop.ts:189:30)
    at Object.listSecrets (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/vaults/VaultOps.ts:254:22)
    at f (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/client/handlers/vaultsSecretsList.ts:37:39)
    at /home/faulkes/matixWorkspace/gitRepos/Polykey/src/vaults/VaultManager.ts:1012:14
    at async withF (/home/faulkes/matixWorkspace/gitRepos/Polykey/node_modules/@matrixai/resources/src/utils.ts:24:12)
    at async constructor_.withVaults (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/vaults/VaultManager.ts:1005:12)
    at async /home/faulkes/matixWorkspace/gitRepos/Polykey/src/client/handlers/vaultsSecretsList.ts:33:14
    at async withF (/home/faulkes/matixWorkspace/gitRepos/Polykey/node_modules/@matrixai/resources/src/utils.ts:24:12)
    at async VaultsSecretsListHandler.handle (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/client/handlers/vaultsSecretsList.ts:22:21)
    at async wrapperDuplex (/home/faulkes/matixWorkspace/gitRepos/Polykey/src/rpc/RPCServer.ts:324:9)

Tracking down this error it seems to be coming from the @ready decorator for the vaultInternal when accessing the vault with VaultInternal.readF().

This only happens when running the commands with npm run polykey -- ..., Doing the same with node dist/bin/polykey does not result in any errors.

Since the npm run polykey is compiling polykey with ts-node and ultimately swc, and the fact we've had problems with swc and decorators before. It's safe the assume this is a swc problem.

To Reproduce

I'm assuming you know how to set up nodes and get them to communicate so I'm skimming over the initial steps here. If not, use the guide in #515 to re-create this.

1. Start two nodes on the local network. Make sure you start these nodes using npm run polykey -- agent start ....
2. Get the two nodes to communicate with each other by providing connection info and pinging each other.
3. Have the nodes trust each other
4. create a vault someVault on NodeB and add a secret
5. Have NodeA clone a vault from NodeA with npm run polykey -- --node-path tmp/nodeA vaults clone <NodeBID> someVault
6. Attempt to access the cloned vault with npm run polykey -- --node-path tmp/nodeA secrets list someVault. This should end up throwing the error on NodeA

Expected behaviour

This should result in listing the secret in the vault.

Platform (please complete the following information)

• Nixos
• Node

Additional context

• Related Create tutorial for agent-agent interactions #515

[CMCDragonkai]

A few things to try here.

Check my existing issues in swc: https://github.com/swc-project/swc/issues/created_by/cmcdragonkai

And update swc to the latest to see if it solves the problem.

And then drill down to see if it can be fixed, or a new upstream issue must be created.

[CMCDragonkai]

You can monkey patch the node_modules/@matrixai/async-init/dist/CreateDestroyStartStop.js, and then run dist/bin/polykey to compare the tsc generated output with npm run ts-node -- polykey with swc generated output.

By checking the this and this[utils_1.initLock] you can sort of debug and trace backwards why this symbol property is not existing or undefined.

[CMCDragonkai]

It does not look like one of the existing issues in swc that I posted, so it could be a new upstream bug.

But first thing to do is update SWC to latest then re-run.

[CMCDragonkai]

Can you confirm @tegefaulkes and close if done.

[tegefaulkes]

I just did some manual testing and we can see that it is all working now.

If I recall, previously the problem was that after cloning accessing the secret would throw. we needed to restart the node to access the secret.

Reading over the issue recall this being a problem with how we used the async-init decorators improperly. It has been fixed in the mean time.

I'm going to close this issue.