ceramicstudio/js-3id-did-provider

authMap is undefined

Schwartz10 opened this issue · 5 comments

Schwartz10 commented

This issue seems to sporadically pop up for me, but occasionally when i create a new instance of ThreeID, I get an error authMap is undefined

Sorry that I don't have great replication steps... It seems very random

My ceramic daemon looks like:

ceramic_1  | Ceramic API running on port 7007
ceramic_1  | (node:1) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'codec' of undefined
ceramic_1  |     at ClassIsWrapper.equals (/js-ceramic/node_modules/cids/src/index.js:297:33)
ceramic_1  |     at Document._findIndex (/js-ceramic/packages/core/lib/document.js:178:19)
ceramic_1  |     at Document._isCidIncluded (/js-ceramic/packages/core/lib/document.js:189:28)
ceramic_1  |     at Document._fetchLog (/js-ceramic/packages/core/lib/document.js:151:24)
ceramic_1  |     at /js-ceramic/packages/core/lib/document.js:137:40
ceramic_1  |     at run (/js-ceramic/node_modules/p-queue/dist/index.js:157:104)
ceramic_1  |     at PQueue._tryToStartAnother (/js-ceramic/node_modules/p-queue/dist/index.js:105:17)
ceramic_1  |     at /js-ceramic/node_modules/p-queue/dist/index.js:171:18
ceramic_1  |     at new Promise (<anonymous>)
ceramic_1  |     at PQueue.add (/js-ceramic/node_modules/p-queue/dist/index.js:152:16)
ceramic_1  | (Use `node --trace-warnings ...` to show where the warning was created)
ceramic_1  | (node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
ceramic_1  | (node:1) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
ceramic_1  | (node:1) UnhandledPromiseRejectionWarning: TypeError: Cannot read property 'codec' of undefined
ceramic_1  |     at ClassIsWrapper.equals (/js-ceramic/node_modules/cids/src/index.js:297:33)
ceramic_1  |     at Document._findIndex (/js-ceramic/packages/core/lib/document.js:178:19)
ceramic_1  |     at Document._isCidIncluded (/js-ceramic/packages/core/lib/document.js:189:28)
ceramic_1  |     at Document._fetchLog (/js-ceramic/packages/core/lib/document.js:151:24)
ceramic_1  |     at /js-ceramic/packages/core/lib/document.js:137:40
ceramic_1  |     at run (/js-ceramic/node_modules/p-queue/dist/index.js:157:104)
ceramic_1  |     at PQueue._tryToStartAnother (/js-ceramic/node_modules/p-queue/dist/index.js:105:17)
ceramic_1  |     at /js-ceramic/node_modules/p-queue/dist/index.js:171:18
ceramic_1  |     at new Promise (<anonymous>)
ceramic_1  |     at PQueue.add (/js-ceramic/node_modules/p-queue/dist/index.js:152:16)
ceramic_1  | (node:1) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 4)

But it's unclear if these issues with codec are causing the problem

Schwartz10 commented

Also, I'm not 100% sure this isn't something I'm doing on my end, but it's possible sometimes the DID returned using authSecret is sometimes different than what it is after creating it (no ceramic restarts).

It seems super spontaneous when these two things happen, which is why I feel like they might be related?

oed commented

Not sure what could be going on here. If you end up being able to replicate it more reliably that would be very helpful :)

Schwartz10 commented

Just an FYI - when i choose to use seed > authSecret, I never see this error. I also have yet to get mismatching DIDs

Schwartz10 commented

@oed some notes from our debug meeting:

  • It looks like in some environments and circumstances - 2 calls to Ceramic to create an authSecret get made. We weren't sure why that was happening.
  • In my web application, the second authSecret call actually created a different did. This ends up causing bugs downstream because the first call to ThreeID.create gives back a different DID than the subsequent ThreeID.create calls.
  • In your test suite, 2 calls were made to authSecret but the same DID was created.
  • In 3ID connect, 1 call was made to authSecret
oed commented

This still needs to be investigated, but heads up that v1 of 3id-did-provider has now been released @Schwartz10