## Problem GitLab Geo has a hardcoded 8-hour (28,800 seconds) timeout for blob downloads that cannot be adjusted per site. This causes sync failures (with the message `Sync timed out after 28800`) for very large LFS objects (5+ GB) that require longer transfer times, leaving them stuck in an inconsistent "started" state rather than properly failing. **Current behavior:** * Large LFS objects timeout after 8 hours during Geo sync * Objects remain in "started" state (state: 1) instead of "failed" state (state: 3) * Sync retries every 8-9 hours but consistently fail with "Sync timed out after 28800" **Impact:** * Affects GitLab Dedicated migrations with large LFS objects * Requires manual intervention to resolve sync failures * 99%+ of smaller objects sync successfully ## Solution Make the blob download timeout configurable at the Geo site level to accommodate different network conditions and file sizes. **Implementation approach:** 1. Add configurable timeout setting to Geo site configuration 2. Update `Geo::BlobDownloadService::LEASE_TIMEOUT` to use site-specific value 3. Provide reasonable defaults while allowing customization ## Current Workaround Manual resolution process: 1. Download objects from primary S3 bucket 2. Upload to secondary S3 bucket at same path 3. Manually mark as synced/verified in Geo registry This workaround was used successfully for 3 large LFS objects (5-8 GB each) during a recent GitLab Dedicated migration. ## Related Issues * GitLab issue #552408 (registry state machine issues) * Observed in GitLab Dedicated migrations with multi-gigabyte LFS objects * https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/dedicated-migrations/-/work_items/116 * https://gitlab.com/gitlab-com/gl-infra/gitlab-dedicated/dedicated-migrations-group/dedicated-migrations/-/work_items/122