Skip to content

Feat/no random access storage in tests#1232

Merged
RangerMauve merged 26 commits intomainfrom
feat/no-random-access-storage-in-tests
Mar 16, 2026
Merged

Feat/no random access storage in tests#1232
RangerMauve merged 26 commits intomainfrom
feat/no-random-access-storage-in-tests

Conversation

@RangerMauve
Copy link
Copy Markdown
Contributor

Closes #1208

@RangerMauve RangerMauve marked this pull request as ready for review February 24, 2026 20:42
@RangerMauve RangerMauve requested review from achou11 and gmaclennan and removed request for gmaclennan February 24, 2026 20:43
Copy link
Copy Markdown
Member

@achou11 achou11 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

More of an initial glance than a deep review

Haven't wrapped my head around lower level changes making use of ReadyResource (hoping Gregor can provide some eyes on that). Changes to the tests seem to make sense to me though!


test('Consistent storage folders', async (t) => {
// TODO: Figure kout consistant storage with rocksdb
test.skip('Consistent storage folders', async (t) => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what's going on here?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This test only made sense with random-access-storage. This won't be relevant once we migrate to rocksdb so I'm adding a TODO to revisit it when we get to the hypercore migration for it

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an important enough test that I think it's important to have something prior to migration - if the folders are not consistent, persistence is lost. This should be possible to implement with random-access-file instead of random-access-memory.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

re-added

async _close() {
await Promise.all(
[...this.#hyperdrives.values()].map((drive) =>
drive.ready().then(() => drive.close())
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awaiting drive.ready() is not necessary, drive.close() will await any _open().

this.#writerKey = null
}

async _open() {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggest we keep the setup in the constructor, that way we don't need to handle the case where writer and writerKey are null. Then in _open only

await Promise.all(
[...this.#hyperdrives.values()].map((drive) => drive.ready())
)

That ensures that close() works as expected.


test('Consistent storage folders', async (t) => {
// TODO: Figure kout consistant storage with rocksdb
test.skip('Consistent storage folders', async (t) => {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an important enough test that I think it's important to have something prior to migration - if the folders are not consistent, persistence is lost. This should be possible to implement with random-access-file instead of random-access-memory.

Copy link
Copy Markdown
Member

@gmaclennan gmaclennan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry it took me a while to fully review this. I think wrapping initialization code in _open() and adding a requirement to await .ready() for classes that use Ready Resource opens up new possibilities for race conditions in the future and is not necessary - the main issue with the test errors were related to closing not opening. I've created a PR #1245 that reverts the async initialization code but keeps the close code. The tests still pass (fingers crossed CI does too!) with random-access-file. TL;DR this keeps the parts of this PR that solve the issue with async storage, and removes the parts which in my view just create additional race-condition opportunities.

* chore: auto-open resources

* chore: increase CI timeout
@RangerMauve RangerMauve requested a review from gmaclennan March 16, 2026 17:45
Copy link
Copy Markdown
Member

@gmaclennan gmaclennan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm once CI passing

@RangerMauve RangerMauve enabled auto-merge (squash) March 16, 2026 19:26
@RangerMauve RangerMauve merged commit 4584233 into main Mar 16, 2026
11 checks passed
@RangerMauve RangerMauve deleted the feat/no-random-access-storage-in-tests branch March 16, 2026 19:32
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

Successfully merging this pull request may close these issues.

remove random access storage from tests

3 participants