You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 9, 2021. It is now read-only.
The root cause seems to be that the access controller db created is correctly synced from the test client to the pinning node, but when the pinning node tries to open it immediately after (as part of the , it sometimes hangs (~50%). This fails silently, and the only way it manifests itself is that the HAS_ENTRIES response isn't sent with the updated number of entries, which is why the tests are failing. This looks like it could be an issue within ipfs (or at least the setup used in the test); a test was put in to show how consecutive fetches to the access dag node can fail.
The text was updated successfully, but these errors were encountered:
The two tests that check whether thread data has been correctly synced to the server and then back to a new client are currently failing, and are skipped. (see https://github.com/3box/3box-pinning-node/blob/develop/src/__tests__/pinning.test.js)
The root cause seems to be that the access controller db created is correctly synced from the test client to the pinning node, but when the pinning node tries to open it immediately after (as part of the , it sometimes hangs (~50%). This fails silently, and the only way it manifests itself is that the
HAS_ENTRIES
response isn't sent with the updated number of entries, which is why the tests are failing. This looks like it could be an issue within ipfs (or at least the setup used in the test); a test was put in to show how consecutive fetches to the access dag node can fail.The text was updated successfully, but these errors were encountered: