同步功能异常

[hellofreud]

docker部署的，同步功能始终不太稳定，大概率同步会失败

[AmintaCCCP]

问题分析

感谢反馈！通过分析代码，我发现 ERR_CONNECTION_RESET 错误可能由以下几个原因导致：

可能的原因

1. Nginx 超时配置不足

   • 当前 proxy_read_timeout 设置为 120 秒
   • 当 starred 仓库数量较多时，同步操作可能超时

2. 大数据量同步性能瓶颈

   • 全量同步时会执行大量数据库操作（删除 + 插入）
   • SQLite 事务锁可能导致长时间阻塞

3. Docker 网络问题

   • backend 容器可能未完全就绪就开始接受请求
   • 容器间网络连接不稳定

---

需要补充的信息

为了更准确地定位问题，请提供以下信息：

1. GitHub Star 数量

大约有多少个 starred 仓库？

原因：数据量直接影响同步耗时。如果有数千个仓库，120 秒超时可能不够。

2. Docker 容器日志

docker-compose logs backend --tail=100

原因：日志中可能包含具体的错误信息，如数据库锁定、内存不足等。

3. 部署环境

• 是本地服务器还是云服务器？
• 如果是云服务器，是哪个服务商/地区？
• 是否使用了反向代理（如 Cloudflare、Nginx Proxy Manager）？

原因：某些网络环境可能有连接时间限制或特殊的安全策略。

4. 复现频率

• 每次同步都失败，还是偶尔成功？
• 刚启动容器后第一次同步是否正常？

原因：如果是间歇性失败，可能是资源竞争或网络波动；如果是首次成功后续失败，可能是数据累积导致。

5. 浏览器开发者工具信息

按 F12 打开开发者工具 → Network 标签页 → 找到失败的请求 → 查看：

• 请求耗时多久？
• Response Headers 中是否有错误信息？

原因：可以确认是请求超时还是连接被主动断开。

---

收到以上信息后，我会进一步排查并提供针对性的修复方案。

[AmintaCCCP]

Hi @hellofreud, thank you for reporting the sync instability issue! This has been fixed in v0.5.8.

In PR #144, we addressed the ERR_CONNECTION_RESET problem with the following changes:

Frontend (backendAdapter.ts):

• Added method with exponential backoff (1s, 2s, 4s, up to 3 retries)
• Retryable error types: ERR_CONNECTION_RESET, ERR_CONNECTION_CLOSED, AbortError (timeout), Failed to fetch, NetworkError
• All sync methods (syncRepositories, fetchRepositories, syncReleases, fetchReleases) now use fetchWithRetry
• Frontend sync timeout increased from 30s to 120s

Nginx configuration:

• proxy_read_timeout: 120s -> 300s
• proxy_send_timeout: 120s -> 300s
• Added proxy_connect_timeout: 30s
• Added proxy_buffering off (streaming, no disk buffering)
• client_max_body_size: 50m -> 100m

Additionally, PR #142 fixed a data-loss race condition where repos could disappear if the page was refreshed within 2 seconds of syncing.

Please update to v0.5.8 and try syncing again: https://github.com/AmintaCCCP/GithubStarsManager/releases/tag/v0.5.8

If the issue persists, please share your Docker container logs () and we will investigate further.