ITADN

repo-archive queue: unmarshal fails after upgrade to v1.26 (ArchiveRequest schema change)

#38272OpenVinod-OAI 创建于 2026-06-29
V
Vinod-OAIcommented
### Description After upgrading Gitea from **1.25.x** to **1.26.x**, the `repo-archive` unique queue can contain jobs serialized with the old `ArchiveRequest` JSON shape. Workers on 1.26 fail to unmarshal those items and log errors like: ```text .../queue/workerqueue.go:155:(*WorkerPoolQueue).unmarshal() [E] Failed to unmarshal item from queue "repo-archive": json: unable to unmarshal into Go convert.Conversion within "/Repo/Units/0/Config": cannot derive concrete type for nil interface with finite type set ``` ### Root cause `ArchiveRequest` changed between releases (see #35514 / subpath archive work in 1.26): **v1.25** (`services/repository/archiver/archiver.go`): ```go type ArchiveRequest struct { RepoID int64 Type git.ArchiveType CommitID string archiveRefShortName string } ``` **v1.26+**: ```go type ArchiveRequest struct { Repo *repo_model.Repository // includes Units[].Config (interface types) Type repo_model.ArchiveType CommitID string Paths []string archiveRefShortName string } ``` The `repo-archive` queue persists JSON via `WorkerPoolQueue`. Jobs enqueued under 1.25 are not compatible with the 1.26 struct, especially `Repo.Units[0].Config` where `convert.Conversion` cannot be derived from stored JSON. ### Impact - Queue workers repeatedly log unmarshal errors for stale items. - With `STREAM_ARCHIVES=false`, full-repo archive API requests can hang in `Await()` if the unique set still thinks a job exists but nothing processes successfully. - Workaround: Site Administration → Monitor → Queues → `repo-archive` → **Remove all items** (and optionally clear stuck `repo_archiver` rows with `status = 0`). ### Steps to reproduce 1. Run Gitea **1.25.x** with `STREAM_ARCHIVES=false` (or otherwise enqueue full-repo archive jobs into `repo-archive`). 2. Trigger at least one full-repo archive download so jobs sit in the persistent queue (level/redis). 3. Upgrade to **1.26.x** without flushing/clearing the `repo-archive` queue. 4. Observe unmarshal errors in logs; full-repo archive HTTP requests may hang. ### Expected behavior One of: - Queue is automatically invalidated / migrated on upgrade when `ArchiveRequest` schema changes. - Upgrade docs explicitly instruct clearing `repo-archive` before/after upgrade. - Queue payload stores a version-stable minimal struct (e.g. `RepoID` + `CommitID` + `Paths`) instead of full `*Repository`. ### Actual behavior Stale 1.25 queue payloads break 1.26 workers; errors repeat until an admin manually clears the queue. ### Gitea Version Observed on **1.26.2** after upgrade from **1.25.x**. Still present in **1.26.4** (`archiver.go` unchanged). Not fixed on `main` as of June 2026. ### Environment - Queue: default persistent unique queue (`repo-archive`) - `STREAM_ARCHIVES=false` forces queued full-repo archives (subpath `?path=...` streams on 1.26 and bypasses the queue) ### Related issues - #27945 (stuck `repo-archive` queue — workaround: clear queue) - #26843 (JSON queue marshal/unmarshal limitations) - #33862 (infinite archive polling — cleared 1M+ queue items) These do not document the **1.25 → 1.26 `ArchiveRequest` breaking schema change** specifically. ### Suggested fix - On startup after upgrade, detect incompatible `repo-archive` items and drop them (or reset the queue), **or** - Revert queue payload to a minimal serializable struct and load `Repository` in the worker handler.
1 条评论