* fix: remove timeout on default DHT operations
This removes the timeout by default for DHT operations. In particular
this causes issues with ProvideMany requests which can take an
indeterminate amount of time, but really these should just respect
context timeouts by default. Users can still specify timeouts here if
they want, but by default they will be set to "0" which means "no
timeout".
This is unlikely to break existing users of custom routing, because
there was previously no utility in configuring a router with timeout=0
because that would cause the router to immediately fail, so it is
unlikely (and incorrect) if anybody was using timeout=0.
* fix: remove 5m timeout on ProvideManyRouter
For context see
5fda291b66
---------
Co-authored-by: Marcin Rataj <lidel@lidel.org>
This fixes a deadlock introduced in 1457b4fd4a.
We can't use the coreapi here because it will try to take the PinLock (RLock) again, so revert this small part of 1457b4fd4a.
This used cause a deadlock when concurrently running `ipfs dag import` concurrently with the GC.
The bug is that `ipfs dag import` takes an RLock with the PinLock.
*the cars are imported, leaving a wide window of time*
Then GC Takes a Lock on that same RWMutex while taking the GC Lock (it blocks because it waits for the RLock to be released).
Then the car imports are finished and `ipfs dag import` tries to aqcuire the PinLock (doing an RLock) again in `Api().Pin`.
However at this point the RWMutex is starved, the runtime put a fence in front of RLocks if a Lock has been waiting for too lock (else you could have an endless stream of RLock / RUnlock forever delaying a Lock to ever go through).
The issue is that `ipfs dag import`'s original RLock which is blocking everyone will be released once it returns, which only happens when `Api().Pin` completes.
So we have a deadlock (ABA kind ?), because `ipfs dag import` waits on the GC Lock, which waits on `ipfs dag import`.
Calling the Pinner directly does not acquire the PinLock again, and thus does not have this issue.
- don't bypass the CoreApi
- don't use a goroutine and return channel for `importWorker`, when what's happening is really just a synchronous call
- only `PinLock()` when we are going to pin
- use `cid.Set` instead of an explicit map
- fail the request early if any pinning fail, no need to try to pin more if the request failed already
* feat(gateway): IPNS record response format
* docs(rpc): mark as experimental: routing provide, get, put
Co-authored-by: Marcin Rataj <lidel@lidel.org>
* fix(gateway): do not convert unixfs/raw into dag-* unless explicit
* fix(gateway): keep only dag-json|dag-cbor handling
* fix: allow requesting dag-json as application/json
- adds bunch of additional tests including JSON file on UnixFS
- fix: dag-json codec (0x0129) can be returned as plain json
- fix: json codec (0x0200) cna be retrurned as plain json
* fix: using ?format|Accept with CID w/ codec works
* docs(changelog): cbor and json on gateway
Co-authored-by: Marcin Rataj <lidel@lidel.org>
Block/CAR responses always had single explicit type, and we did not bother
with implementing/testing lists.
With the introduction of JSON people may start passing a list.
This is the most basic fix which will return on the first matching
type (in order). This does not implements weights (can be added in
future, if needed).
Closes#9520
