Skip to content
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.

WIP callbacks -> async / await #82

Closed
wants to merge 8 commits into from

Conversation

dirkmc
Copy link
Contributor

@dirkmc dirkmc commented Feb 21, 2019

BREAKING CHANGE: This change replaces callbacks with async / await

I refactored a few things while I was making this change:

  • queue.js
    • functionally equivalent, but now uses Iterators instead of an async/queue
    • stops any running workers if an error is thrown
    • has a mechanism to stop a query once the required number of results have been fetched
    • ensure peers are unique by peer id (before they were only unique by Object reference)
  • providers.js
    • now ensures that addProvider(), getProviders() and _cleanup() are synchronized (using a p-queue)
    • now cleans up any expired entries (previously expired entries would only be cleaned up if all peer ids for a given CID had expired)
    • add items to the cache any time we go to the datastore (previously we would cache on addProvider() but not on getProviders())
  • random-walk.js
  • getMany()
    • Fix bug where requesting a single value would fail if the value was not found in the local datastore (ie before it wouldn't go out to the DHT to look for it. Now it does)
  • stop()
    • Ensure all running queries are stopped when the DHT is stopped
  • Moved all pull-streams into a single class so that we can easily replace with Iterators when the Connection interface has been updated

@dirkmc dirkmc force-pushed the feat/async-await branch 7 times, most recently from 579eda7 to 1247bc4 Compare February 27, 2019 19:29
@dirkmc dirkmc marked this pull request as ready for review February 27, 2019 19:32
Copy link
Member

@vasco-santos vasco-santos left a comment

Choose a reason for hiding this comment

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

Thanks for this PR @dirkmc . So great to have this progress 💪 Also thanks for improving some docs not related =D

I made a first pass through the initial src files, as this is a really big PR, and left a few comments

In a next step we could get rid of pull-streams. Maybe the first step could be to convert the pull-streams that are from other modules to streams (and separate all them to a separate file, for easy plug and play afterward). When this module need to expose a pull-stream to other module, we may implement a node stream as well, and have a converter in the end that we will be able to remove afterward as well. What do you think?

package.json Show resolved Hide resolved
src/index.js Outdated Show resolved Hide resolved
src/index.js Outdated Show resolved Hide resolved
src/index.js Outdated Show resolved Hide resolved
@dirkmc
Copy link
Contributor Author

dirkmc commented Mar 5, 2019

Yes I think that makes sense 👍

Copy link
Member

@vasco-santos vasco-santos left a comment

Choose a reason for hiding this comment

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

I reviewed src/private and src/random-walk now and left a few more comments

src/private.js Outdated Show resolved Hide resolved
src/private.js Outdated Show resolved Hide resolved
BREAKING CHANGE: All places in the API that used callbacks are now replaced with async/await
@kumavis
Copy link
Contributor

kumavis commented Apr 22, 2019

I don't mean to disparage the great effort here but in my experience large on-going refactors are a bad idea when working with multiple contributors. You end up in merge conflict hell and in resolving them its easy to run over patches that were merged after the refactor started.

Also seems this one has also outgrown its original async/await focus and has become a something more, possibly now a sort of too-big-to-fail PR that blocks or at least complicates all development.

I don't mean to sound dire, I've just lived through too many of these. And I'm mostly an outsider here so I'm not trying to tell someone what to do but I'd recommend (1) resolving and merging this asap (2) using the code here to break this down into multiple smaller PRs

happy to do my part and not just comment : )

I anticipate working very closely with the dht this month

}

const run = new Run(this.dht, this.key, this.makePathQuery, this._log)
this.run = run
Copy link
Contributor

Choose a reason for hiding this comment

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

seems like this.run accidentally clashes with the run function defined on the Query class. I guess this could be an intentional override, but if so it should be heavily commented because its surprising

Copy link
Contributor

Choose a reason for hiding this comment

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

@dirkmc could you clarify if this is intentional or not

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@kumavis it's not intentional - thanks for pointing it out.

I think it's best to hold off on updating this PR until the dependencies are released

Copy link
Contributor

Choose a reason for hiding this comment

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

opened an issue #114

* unnecessarily.
*/
stop () {
this.run && this.run.stop()
Copy link
Contributor

Choose a reason for hiding this comment

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

this seems like a mistake (as I elsewhere noted about this.run). I would expect this.run to always be truthy because run is defined on the class

"base32.js": "~0.1.0",
"chai-checkmark": "^1.0.1",
"cids": "~0.5.7",
"debug": "^4.1.1",
"err-code": "^1.1.2",
"hashlru": "^2.3.0",
"heap": "~0.2.6",
"interface-datastore": "~0.6.0",
"interface-datastore": "ipfs/interface-datastore#refactor/async-iterators",
Copy link
Contributor

Choose a reason for hiding this comment

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

issue with interface-datastore dep ref

➜ npm i
npm ERR! code 1
npm ERR! Command failed: git checkout refactor/async-iterators
npm ERR! error: pathspec 'refactor/async-iterators' did not match any file(s) known to git

Copy link
Contributor

@kumavis kumavis Apr 22, 2019

Choose a reason for hiding this comment

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

looks like merged and branch deleted 👍 ipfs/interface-datastore#25

Copy link
Contributor

Choose a reason for hiding this comment

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

not published yet though, I'll point to the commit for now

"multihashing-async": "~0.5.2",
"peer-id": "~0.12.2",
"peer-info": "~0.15.1",
"multihashing-async": "multiformats/js-multihashing-async#feat/async-iterators",
Copy link
Contributor

Choose a reason for hiding this comment

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

published as 0.7.0 👍

@kumavis
Copy link
Contributor

kumavis commented Apr 22, 2019

Theres some git branch dep hell going on as async/await branches gets merged deleted

@kumavis
Copy link
Contributor

kumavis commented Apr 22, 2019

@vasco-santos
Copy link
Member

Thanks for your feedback @kumavis

We will need to update this PR with the new changes, and we will do it while the remaining dependencies are not ready. Hopefully, we will be able to get this PR more ready to merge in the next month

@dirkmc
Copy link
Contributor Author

dirkmc commented Apr 29, 2019

@kumavis if you are interested in helping out with DHT work it would be very welcome. This issue is one we will need to implement in both Go and Javascript: libp2p/go-libp2p-kad-dht#323

@kumavis
Copy link
Contributor

kumavis commented Apr 30, 2019

@dirkmc hey/ took a stab at adding your refactors in a non-breaking way to reduce conflicts #108

@kumavis
Copy link
Contributor

kumavis commented May 23, 2019

@dirkmc theres a lot of great work in here that i dont want to get lost, but extracting the high level changes from the diff is a bit difficult -- if there are any additional fixes or changes in this PR that are not enumerated in the PR description, could you add them so I can make sure they aren't lost? Thanks!

@kumavis
Copy link
Contributor

kumavis commented Jun 3, 2019

heres where we're at getting these changes in master (may have missed something)

  • src/query/workerQueue
    • cb -> async
    • uses Iterators instead of an async/queue
    • stops any running workers if an error is thrown
    • has a mechanism to stop a query once the required number of results have been fetched
    • ensure peers are unique by peer id (before they were only unique by Object reference)
  • providers
    • cb -> async
    • now ensures that addProvider(), getProviders() and _cleanup() are synchronized (using a p-queue)
    • now cleans up any expired entries (previously expired entries would only be cleaned up if all peer ids for a given CID had expired)
    • add items to the cache any time we go to the datastore (previously we would cache on addProvider() but not on getProviders())
  • random-walk
  • dht/index
    • cb -> async
    • getMany()
      • Fix bug where requesting a single value would fail if the value was not found in the local datastore (ie before it wouldn't go out to the DHT to look for it. Now it does)
      • async Iterator interface
    • stop()
      • Ensure all running queries are stopped when the DHT is stopped
  • Move all pull-streams into a single class so that we can easily replace with Iterators when the Connection interface has been updated
    • src/rpc
    • src/providers
    • src/network

kumavis added a commit that referenced this pull request Jun 3, 2019
kumavis added a commit that referenced this pull request Jun 3, 2019
kumavis added a commit that referenced this pull request Jun 3, 2019
This was referenced Jun 3, 2019
vasco-santos pushed a commit that referenced this pull request Jun 10, 2019
* refactor(async): providers refactor from #82

* test: providers dedupes redundant providers

* added feedback from PR review

* aegir - increase bundle size to 222kB
@vasco-santos
Copy link
Member

@kumavis @dirkmc does it make sense to close this PR and work from the current state of things?

We already have a lot of work done here, as well as the current status check list from @kumavis to iterate. I hope to get the interface-connection work finished soon, so that we can avance with this

@dirkmc
Copy link
Contributor Author

dirkmc commented Aug 26, 2019

Makes sense to me - thanks for the help with getting this into master @kumavis

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

Successfully merging this pull request may close these issues.

3 participants