Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tests failing #6

Open
DougAnderson444 opened this issue Sep 29, 2020 · 6 comments
Open

tests failing #6

DougAnderson444 opened this issue Sep 29, 2020 · 6 comments

Comments

@DougAnderson444
Copy link

I ran into issues with the dat-SDK and ran the tests for this package.

Are the tests failing for anyone else?

RangerMauve/hyper-sdk#66

@DougAnderson444
Copy link
Author

DougAnderson444 commented Sep 30, 2020

@RangerMauve I noticed @tinchoz49 has got some changes on the go with the https://github.com/random-access-storage/random-access-chrome-file/tree/tinchoz49/improve-performance branch (the problematic one in RangerMauve/hyper-sdk#66) which might solve some of the issues I've been seeing once they're merged in.

@RangerMauve
Copy link
Collaborator

Does copying those changes into your node_modules and rebuilding help stop the error?

@tinchoz49
Copy link

Hey @DougAnderson444, we have been using that branch of random-access-chrome-file in production for a while I would say it's 90% stable but we got a random issue relating with lock/unlock the resource chrome file and I couldn't get a way to reproduce it. Also the API of the native file that we are using is deprecated so I'm thinking that maybe is a good time to start over that project.

@DougAnderson444
Copy link
Author

That's good to know. I was about to work with your branch but if it's deprecated I agree better use of effort would be re-write to the new API.

@RangerMauve
Copy link
Collaborator

Hmm, I guess I could temporarily remove chrome-file from RAW entirely until somebody implements the new FS API?

@DougAnderson444
Copy link
Author

@RangerMauve either that or perhaps have it gracefully degrade to indexedDB in the event of a DOMException (that's the error I keep seeing with chrome-file), if possible? 🤔

BTW, speaking of idb, I did notice that npm uses the substack version of random-access-idb but I'm seeing it break with Corestore because it allows db.close() (with follow-on issues when it needs to be read next time... because it's busy closing!) whereas https://github.com/random-access-storage/random-access-idb excludes the close and works, but it's not the one in npm and it is missing substacks latest commits. Soooo... I ended up merging these together in my fork and am awaiting r-a-s folks to merge the PR. Not sure which version of idb you wanna use, as I'm sure you're aware there's a few version out there! The certainly confused me at first. 😮

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants