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
