Closed zeeshanakram3 closed 9 months ago
I expected the
supportedObjects
to give proper number. I can get objects fine
@kdembler Addressed in 2bbf0af. You should be able to see the supported objects count now
btw @zeeshanakram3 did you manage to resolve https://github.com/Joystream/storage-squid/issues/1? My squid crashed 1 day after starting
btw @zeeshanakram3 did you manage to resolve Joystream/storage-squid#1? My squid crashed 1 day after starting
I wasn't able to reproduce the error. I will try to test again locally against the mainnet
I wasn't able to reproduce the error. I will try to test again locally against the mainnet
I'd suggest to do it on a server so that it indexes all the time. Locally (only syncing when my laptop was on) it didn't happen to me as well
I'd suggest to do it on a server so that it indexes all the time. Locally (only syncing when my laptop was on) it didn't happen to me as well
After your comment I have dropped my squid, started fresh sync and it crashed again
@zeeshanakram3 one more question: do you think it would be a lot of effort to include storage squid version in argus&colossus status endpoints? https://github.com/Joystream/joystream/issues/4732
@zeeshanakram3 one more question: do you think it would be a lot of effort to include storage squid version in argus&colossus status endpoints? #4732
I will implement it.
- Bump storage node version to v3.11.0 and the storage cli package to v3.3.0
@mnaamani regarding the package versions, shouldn't we bump the major versions in both Argus & Colossus, since we have a breaking change in configuration options (changed --queryNodeEndpoint
to --storageSquidEndpoint
)?
- Bump storage node version to v3.11.0 and the storage cli package to v3.3.0
@mnaamani regarding the package versions, shouldn't we bump the major versions in both Argus & Colossus, since we have a breaking change in configuration options (changed
--queryNodeEndpoint
to--storageSquidEndpoint
)?
That might actually make more sense yes.
Should we also consider forking current master to keep the old version on a separate branch so we can slowly transition all operators just in-case we need to create some important patch while operators are still on older version?
Should we also consider forking current master to keep the old version on a separate branch so we can slowly transition all operators just in-case we need to create some important patch while operators are still on older version?
Yeah, makes sense
Failing integration tests should be fixed by https://github.com/Joystream/storage-squid/pull/13
@zeeshanakram3 could you reply to this? https://github.com/Joystream/joystream/pull/5001#discussion_r1443286342 I think Argus (and Colossus) should still provide valid response for /status request even when the squid is down. Currently we're just forwarding the raw error to the user.
As a counterargument, we need that kind of handling for asset requests as well, not only for status and that currently isn't handled
closes #4957
This PR:
docker-compose.storage-squid.yml
file to run storage-squid servicesstorage-squid
services when running Argus/Colossusgraphql-server