yolo/arr
3
0
Fork 0
Code Issues 12 Pull Requests Actions Packages Projects Releases Wiki Activity

a_failed_rename_leaves_the_row_alone fails in CI because CI is root #256

New Issue
Open
opened 2026-08-25 22:40:07 +01:00 by naps62-yolo · 0 comments
naps62-yolo commented 2026-08-25 22:40:07 +01:00
Owner
Copy Link
Copy Source

movies::tests::a_failed_rename_leaves_the_row_alone has failed on every
main push since it landed in bce3d38. The rust job is the only red one;
web and e2e are green.

thread 'movies::tests::a_failed_rename_leaves_the_row_alone' panicked at
crates/arr-api/src/movies.rs:1861:9:
assertion `left == right` failed
  left: 200
 right: 500

The test freezes the title folder to 0o555 and expects the move to fail:

tokio::fs::set_permissions(&folder, std::fs::Permissions::from_mode(0o555))

CI runs as root — .gitea/workflows/ci.yml calls apt-get install with no
sudo — and root ignores the permission bits, so the rename succeeds and the
handler returns 200. The same test passes on a developer machine, which is why
just ci is green locally and red in CI.

Because nextest cancels on first failure, one root-only failure hides the other
506 tests in that job. That is the more expensive half of this.

Options, roughly in order of preference:

  1. Make the failure not depend on the caller's privilege — point the
    destination at something a rename cannot succeed onto regardless of uid
    (an existing non-empty directory, or a path component that is a file).
  2. Skip the test when geteuid() == 0, and say so in the skip reason.
  3. Run the rust job as a non-root user.

(1) keeps the assertion honest everywhere and is the only one that still tests
anything in CI.

Found while merging the Subtitles milestone into main; the failure predates
that merge and is unrelated to it.

`movies::tests::a_failed_rename_leaves_the_row_alone` has failed on every `main` push since it landed in bce3d38. The `rust` job is the only red one; `web` and `e2e` are green. ``` thread 'movies::tests::a_failed_rename_leaves_the_row_alone' panicked at crates/arr-api/src/movies.rs:1861:9: assertion `left == right` failed left: 200 right: 500 ``` The test freezes the title folder to `0o555` and expects the move to fail: ```rust tokio::fs::set_permissions(&folder, std::fs::Permissions::from_mode(0o555)) ``` CI runs as root — `.gitea/workflows/ci.yml` calls `apt-get install` with no `sudo` — and root ignores the permission bits, so the rename succeeds and the handler returns 200. The same test passes on a developer machine, which is why `just ci` is green locally and red in CI. Because nextest cancels on first failure, one root-only failure hides the other 506 tests in that job. That is the more expensive half of this. Options, roughly in order of preference: 1. Make the failure not depend on the caller's privilege — point the destination at something a rename cannot succeed onto regardless of uid (an existing non-empty directory, or a path component that is a file). 2. Skip the test when `geteuid() == 0`, and say so in the skip reason. 3. Run the `rust` job as a non-root user. (1) keeps the assertion honest everywhere and is the only one that still tests anything in CI. Found while merging the Subtitles milestone into `main`; the failure predates that merge and is unrelated to it.
naps62-yolo added the area/cidifficulty/easytype/test labels 2026-08-25 22:40:14 +01:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
arr-api
 area/ci
CI and test harness
 area/compat
arr-compat
 area/core
arr-core
 area/daemon
arr-daemon
 area/db
arr-db
 area/dl
arr-dl
 area/indexer
arr-indexer
 area/infra
workspace and tooling
 area/meta
arr-meta
 area/parse
arr-parse
 area/probe
arr-probe
 area/subs
arr-subs crate: providers, extraction, translation, sync
 area/web
web/
 difficulty/easy
bounded, obvious approach, few files
 difficulty/hard
subtle correctness or cross-cutting
 difficulty/moderate
multiple files, judgement, an interface to design
 difficulty/trivial
one file, mechanical, no design decisions
 phase/1-skeleton
workspace, CI, config, database, empty API and SPA
 phase/2-logic
parsing and policy engine, pure, no network
 phase/3-sourcing
TMDB and Prowlarr, read-only
 phase/4-movies
movies end to end
 phase/5-ui
search, buckets, library views, queues
 phase/6-tv
seasons, episodes, tracking, derived status
 phase/7-people
owner tags and notifications
 phase/8-compat
Jellyseerr shim
 phase/9-subtitles
build order: subtitles, DESIGN.md §15
 type/bug
type/chore
type/feature
type/test
No Label area/ci difficulty/easy type/test
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
hermes (Hermes (agent)) naps62 (Miguel Palhas) naps62-yolo (naps62-yolo (agent))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yolo/arr#256
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?