The recommended way to deploy a migrated Solana squid is the zero-downtime resync procedure: deploy into a new slot, wait for it to catch up, then swap the production tag. That gives you a clean re-index with the new field selection and catches mistakes in cold blocks before traffic hits the new deployment.Documentation Index
Fetch the complete documentation index at: https://docs.sqd.dev/llms.txt
Use this file to discover all available pages before exploring further.
Why you might need this
Re-syncing a Solana squid is expensive in time and Portal traffic. If your indexer has been running for months and a re-sync would take days, you may want to keep the current cold-block state and only re-deploy the processor.Procedure
Assuming your squid is version-controlled and has one processor:- Commit your updated squid code.
-
Stop your Cloud squid deployment.
- Reset your repo to the state before the updates.
- Add the
tofield to the argument of the.setBlockRangeDataSourceBuildercall (likely in./src/main.ts). Set it to the current slot number. - Update your deployment without resetting its database.
- Watch your squid’s logs. It should be repeatedly terminating (nothing to do) and restarting.
-
Connect to the squid’s database and update the
heightfield of the status schema to contain slot instead of the block height of the block mentioned there. -
Verify the
heightfield updated successfully by re-reading the status schema. - Reset your codebase to its updated version and redeploy your squid again.