gobengo
commented
1 year ago tldr
- upload-api tests use npm
testcontainers, which depends on a docker daemon, and may have quirks depending on what specfiically powers your 'docker daemon' - try with
TESTCONTAINERS_RYUK_DISABLED=true
Debugged error message into ava as
- https://github.com/avajs/ava/blob/52b22700e995eda3fd0f95e4b8fd31ab3c7644be/lib/test.js#L560
- https://github.com/avajs/ava/blob/647d3e15305ae5fdfccf3009fdd1ef18a82af6a1/lib/runner.js#L537
- weird, the ava process is getting a
beforeExitevent while waiting on testcontainers
- weird, the ava process is getting a
Must be something about how testcontainers interacts with my local docker daemon? (of course)
- I use https://rancherdesktop.io/
- this uses lima under the hood
- I wonder what @olizilla and @vasco-santos use locally to run a docker daemon (if they use a mac)?
Searched 'testcontainers rancher desktop mac' and found
disablying ryuk works better
bengo@bengo ~/protocol.ai/upload-api ⚡ AWS_PROFILE=dotstorage TESTCONTAINERS_RYUK_DISABLED=true npm test
> upload-api@0.0.0 test
> npm test -w api -w carpark -w replicator -w satnav
> @web3-storage/upload-api@3.0.0 test
> ava --node-arguments='--experimental-fetch' --verbose --timeout=60s **/*.test.js
(node:26902) ExperimentalWarning: Fetch is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
(node:26902) ExperimentalWarning: Fetch is an experimental feature. This feature could change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
invocation verification failed {
name: 'Error',
error: true,
stack: 'Error: not found\n' +
' at info (file:///Users/bengo/protocol.ai/upload-api/api/test/service/store.test.js:323:37)\n' +
' at Object.countedFn [as info] (file:///Users/bengo/protocol.ai/upload-api/api/test/helpers/resources.js:204:12)\n' +
' at invoke (file:///Users/bengo/protocol.ai/upload-api/node_modules/@ucanto/server/src/server.js:129:35)\n' +
' at execute (file:///Users/bengo/protocol.ai/upload-api/node_modules/@ucanto/server/src/server.js:90:24)\n' +
' at handle (file:///Users/bengo/protocol.ai/upload-api/node_modules/@ucanto/server/src/server.js:71:24)\n' +
' at processTicksAndRejections (node:internal/process/task_queues:96:5)\n' +
' at async Server.<anonymous> (file:///Users/bengo/protocol.ai/upload-api/api/test/helpers/resources.js:149:33)',
message: 'not found'
}
✔ store › store/add disallowed if invocation fails access verification (8.5s)
✔ upload › upload/remove does not fail for non existent upload (8.5s)
✔ store › store/list does not fail for empty list (8.6s)
✔ upload › upload/list does not fail for empty list (8.6s)
✔ store › store/add allowed if invocation passes access verification (8.6s)
✔ store › store/remove does not fail for non existent link (8.6s)
✔ store › store/add returns done if already uploaded (8.6s)
✔ store › store/add should create a presigned url that can only PUT a payload with the right length (8.6s)
✖ store › store/add should create a presigned url that can only PUT the exact bytes we signed for should fail to upload any other data.
✔ store › store/list returns items previously stored by the user (8.6s)
✔ store › store/remove removes car bound to issuer from store table (8.6s)
✔ store › store/add returns signed url for uploading (8.6s)
✔ store › store/list can be paginated with custom size (8.7s)
✔ upload › upload/add merges shards to an existing item with shards (8.7s)
✔ upload › upload/list returns entries previously uploaded by the user (8.8s)
✔ upload › upload/add inserts into DB mapping between data CID and car CIDs (8.8s)
✔ upload › upload/add does not fail with no shards provided (8.8s)
✔ upload › upload/add can add shards to an existing item with no shards (8.8s)
✔ upload › upload/remove removes all entries when larger than batch limit (8.8s)
✔ upload › upload/remove removes all entries with data CID linked to space (8.8s)
✔ upload › upload/list can be paginated with custom size (8.8s)
─
store › store/add should create a presigned url that can only PUT the exact bytes we signed for
test/service/store.test.js:221
220: })
221: t.is(failChecksum.status, 400, 'should fail to upload any other data.')
222: })
should fail to upload any other data.
Difference:
- 200
+ 400
› file://test/service/store.test.js:221:5
─
1 test failed
npm ERR! Lifecycle script `test` failed with error:
npm ERR! Error: command failed
npm ERR! in workspace: @web3-storage/upload-api@3.0.0
npm ERR! at location: /Users/bengo/protocol.ai/upload-api/api
> @web3-storage/upload-api-carpark@0.0.0 test
> ava --verbose --timeout=60s **/*.test.js
(⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂) ⠏ : ERR! at location: /Users/bengo/protocol.ai/upload-api/api
✔ does not notify event bus when carpark bucket is written with non CAR filesi/api
✔ notifies event bus when new carpark bucket is written
✔ E-IPFS event handler sends message to SQS
─
3 tests passed
> @web3-storage/upload-api-replicator@0.0.0 test
> ava --verbose --timeout=60s **/*.test.js
(⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂) ⠏ : ERR! at location: /Users/bengo/protocol.ai/upload-api/api
✔ copy CARs from origin bucket to replicator bucketengo/protocol.ai/upload-api/api
✔ copy satnav index to replicator bucket
─
2 tests passed
(⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂) ⠏ : ERR! at location: /Users/bengo/protocol.ai/upload-api/api
> @web3-storage/upload-api-satnav@0.0.0 test
> ava --verbose --timeout=60s **/*.test.js
(⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂) ⠏ : ERR! at location: /Users/bengo/protocol.ai/upload-api/api
✔ event-bus › does not notify event bus when a non .idx file is added to the satnav bucket
✔ event-bus › notifies event bus when an .idx file is added to the satnav bucket
✔ satnav-writer › fails if carpark bucket does not have event target filed-api/api
✔ satnav-writer › does not re-create side index if already existing
✔ satnav-writer › creates side index and writes to satnav bucket
─⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂⠂) ⠏ : ERR! at location: /Users/bengo/protocol.ai/upload-api/api
5 tests passed
bengo@bengo ~/protocol.ai/upload-api ⚡- one failing test, which I will debug separately
Context:
Reproduction steps
npm inpm testnpm test(with docker daemon running)Expected behavior
Actual Behavior