Expired session detection fix

[pierreyves258]

📝 Description

Ajout d'information de débug dans les logs sur le parse de la taille du torrent

🎯 Type de changement

Cochez les options pertinentes :

• 🐛 Bug fix (correction d'un problème sans changement majeur)
• ✨ Nouvelle fonctionnalité (ajout de fonctionnalité sans changement majeur)
• 💥 Breaking change (correction ou fonctionnalité qui casse la compatibilité)
• 📚 Documentation (mise à jour de la documentation uniquement)
• 🔧 Configuration / CI/CD (changements de configuration ou workflows)
• ♻️ Refactoring (changements qui n'ajoutent pas de fonctionnalité ni ne corrigent de bugs)
• ⚡ Performance (amélioration des performances)

🔗 Issue liée

Possible fix pour #134
Je ne pense pas que le soucis vienne de la fonction de parse de la taille mais plutot d'un soucis sous-jacent de session
Fixe #134 (comment) car en effet apres que ygege soit lancé depuis quelques jours la session expire et lápi renvoie des code 302 (au lieu de 307 initialement)

🧪 Comment cela a-t-il été testé ?

Décrivez les tests effectués :

Testé en dev avec un call API sur /user et /search

Configuration de test :

• OS : macOS Tahoe
• Runtime : Source

📋 Checklist

Code Quality

• Mon code suit les conventions de style du projet
• J'ai effectué une auto-revue de mon code
• J'ai commenté mon code, particulièrement dans les zones difficiles
• Mes changements ne génèrent aucun nouveau warning

Documentation

• J'ai mis à jour la documentation correspondante (FR & EN si applicable)
• Si API modifiée : docs/api-documentation.md et docs/api-documentation-fr.md mis à jour
• Si configuration modifiée : exemples dans docs/ mis à jour

Tests

• J'ai ajouté des tests prouvant l'efficacité de mon correctif/fonctionnalité
• Les tests unitaires nouveaux et existants passent localement
• Testé avec Docker (si applicable)
• Testé avec Prowlarr/Radarr/Sonarr (si applicable)

Dépendances

• Aucune dépendance externe ajoutée sans justification
• Les modifications dépendantes ont été fusionnées/publiées

🔄 Changements majeurs (si applicable)

Migration requise

📌 Notes supplémentaires

---

Note pour les reviewers :

Summary by CodeRabbit

• Bug Fixes
  • Improved error message for invalid size format to include the original input.
  • Enhanced session expiration detection to recognize HTTP 302 responses in addition to 307.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

Two utility modules receive targeted updates: the parser now includes the input size in error messages for invalid human-readable byte format, while the session manager expands expired session detection to include HTTP 302 responses alongside 307.

Changes

Cohort / File(s)	Summary
Error Messaging src/parser.rs	Dynamic error message for invalid human-readable size format now includes original input value instead of fixed message
Session Expiration Detection src/utils.rs	HTTP 302 status code added to session expiration check alongside existing 307 treatment

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰 A tiny hop, a line here, a line there,
Session checks now with 302 care,
Error messages speak their size with pride,
Small fixes made the code more wide! ✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description is largely complete and follows the template structure. It includes a description, change type selection, linked issues, testing details, and a comprehensive checklist. However, the description mentions 'Ajout d'information de débug' (adding debug information) which relates primarily to parser.rs, while the main behavioral change is the session expiration fix in utils.rs.
Title check	✅ Passed	The title 'Expired session detection fix' aligns with the primary change in src/utils.rs, which updates session expiration detection to treat HTTP 302 status as expired. However, it does not reflect the secondary change in src/parser.rs regarding error message enhancement.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Pommefrais3]

Est ce que cela aurait dû patcher ce genre d'erreur ?

2026-01-09T10:58:16.115073214Z DEBUG ygege::rest::search > Received query: categories=2154&q=Pierre&name=Pierre&sort=seed&order=desc&connarr=true 2026-01-09T10:58:16.115119587Z DEBUG ygege::rest::search > Prowlarr/Jackett detected 2026-01-09T10:58:16.115127308Z DEBUG ygege::rest::search > Performing bulk search across 1 categories: [2154] 2026-01-09T10:58:16.115134230Z DEBUG ygege::rest::search > Starting parallel search across 1 categories 2026-01-09T10:58:16.115155264Z DEBUG ygege::search > Searching for torrents (name: Some("Pierre"), offset: None, category: Some(2154), sub_category: None, sort: Some(Seed), order: Some(Descending)) 2026-01-09T10:58:16.206296627Z DEBUG ygege::utils > Response status code: 302 Found 2026-01-09T10:58:16.206324896Z DEBUG ygege::search > Search response: 302 Found 2026-01-09T10:58:16.206397275Z WARN ygege::rest::search > Search failed for category 2154: Unable to find table 2026-01-09T10:58:16.206404218Z DEBUG ygege::rest::search > Returning 0 merged torrents from 1 categories 2026-01-09T10:58:16.206409364Z INFO ygege::rest::search > 0 torrents found via bulk category search

Le container a 5 heures d'ancienneté et n'est utilisé par prowlarr uniquement pour des recherches donc pas forcément toujours sollicité pendant de longues périodes.

[pierreyves258]

Est ce que cela aurait dû patcher ce genre d'erreur ?

2026-01-09T10:58:16.115073214Z DEBUG ygege::rest::search > Received query: categories=2154&q=Pierre&name=Pierre&sort=seed&order=desc&connarr=true 2026-01-09T10:58:16.115119587Z DEBUG ygege::rest::search > Prowlarr/Jackett detected 2026-01-09T10:58:16.115127308Z DEBUG ygege::rest::search > Performing bulk search across 1 categories: [2154] 2026-01-09T10:58:16.115134230Z DEBUG ygege::rest::search > Starting parallel search across 1 categories 2026-01-09T10:58:16.115155264Z DEBUG ygege::search > Searching for torrents (name: Some("Pierre"), offset: None, category: Some(2154), sub_category: None, sort: Some(Seed), order: Some(Descending)) 2026-01-09T10:58:16.206296627Z DEBUG ygege::utils > Response status code: 302 Found 2026-01-09T10:58:16.206324896Z DEBUG ygege::search > Search response: 302 Found 2026-01-09T10:58:16.206397275Z WARN ygege::rest::search > Search failed for category 2154: Unable to find table 2026-01-09T10:58:16.206404218Z DEBUG ygege::rest::search > Returning 0 merged torrents from 1 categories 2026-01-09T10:58:16.206409364Z INFO ygege::rest::search > 0 torrents found via bulk category search

Le container a 5 heures d'ancienneté et n'est utilisé par prowlarr uniquement pour des recherches donc pas forcément toujours sollicité pendant de longues périodes.

Oui c'est un fix pour cette erreur
Tesable avec cette image pierreyves258/ygege:v0.7.3

[UwUDev]

Avant de merge, elle vient d'où l'autre ip ?? C'est une free box, tu serais pas en train de MITM la ?

[pierreyves258]

Avant de merge, elle vient d'où l'autre ip ?? C'est une free box, tu serais pas en train de MITM la ?

Comme expliqué dans l'issue je l'ai trouvée la
#121 (comment)

Je ne sait pas non plus pourquoi c'est une ip Free mais tout ce que je sait c'est que l'ancienne ne fonctionne pas et celle la oui
#121 (comment)

Pour moi la seule solution fiable pour etre sur c'est ça #131 car je n'ai aucune idée non plus de a qui appartient cette IP, tout ce que je sait c'est que ça fonctionne et ça bypasse cloudflare

[UwUDev]

Ok ok, regarde ça plus en détails quand je serai un PC. On se posait la question car c'est vraiment très étrange que ça finisse sur une freebox

[Pommefrais3]

Est ce que cela aurait dû patcher ce genre d'erreur ?
2026-01-09T10:58:16.115073214Z DEBUG ygege::rest::search > Received query: categories=2154&q=Pierre&name=Pierre&sort=seed&order=desc&connarr=true 2026-01-09T10:58:16.115119587Z DEBUG ygege::rest::search > Prowlarr/Jackett detected 2026-01-09T10:58:16.115127308Z DEBUG ygege::rest::search > Performing bulk search across 1 categories: [2154] 2026-01-09T10:58:16.115134230Z DEBUG ygege::rest::search > Starting parallel search across 1 categories 2026-01-09T10:58:16.115155264Z DEBUG ygege::search > Searching for torrents (name: Some("Pierre"), offset: None, category: Some(2154), sub_category: None, sort: Some(Seed), order: Some(Descending)) 2026-01-09T10:58:16.206296627Z DEBUG ygege::utils > Response status code: 302 Found 2026-01-09T10:58:16.206324896Z DEBUG ygege::search > Search response: 302 Found 2026-01-09T10:58:16.206397275Z WARN ygege::rest::search > Search failed for category 2154: Unable to find table 2026-01-09T10:58:16.206404218Z DEBUG ygege::rest::search > Returning 0 merged torrents from 1 categories 2026-01-09T10:58:16.206409364Z INFO ygege::rest::search > 0 torrents found via bulk category search
Le container a 5 heures d'ancienneté et n'est utilisé par prowlarr uniquement pour des recherches donc pas forcément toujours sollicité pendant de longues périodes.

Oui c'est un fix pour cette erreur Tesable avec cette image pierreyves258/ygege:v0.7.3

Okay le fix fonctionne car le Response status code: 302 est patché mais dans cette version j'ai l'impression que le mode turbo n'est pas pris en compte par rapport à la v0.7.2 de @UwUDev et c'est pour ça qu'il ne récupère pas le token après la demande de magnet !
Pour le moment j'utilise la v0.7.2 avec un suppression des cookies périodiquement pour ne plus faire face à cette erreur.

[pierreyves258]

Est ce que cela aurait dû patcher ce genre d'erreur ?
2026-01-09T10:58:16.115073214Z DEBUG ygege::rest::search > Received query: categories=2154&q=Pierre&name=Pierre&sort=seed&order=desc&connarr=true 2026-01-09T10:58:16.115119587Z DEBUG ygege::rest::search > Prowlarr/Jackett detected 2026-01-09T10:58:16.115127308Z DEBUG ygege::rest::search > Performing bulk search across 1 categories: [2154] 2026-01-09T10:58:16.115134230Z DEBUG ygege::rest::search > Starting parallel search across 1 categories 2026-01-09T10:58:16.115155264Z DEBUG ygege::search > Searching for torrents (name: Some("Pierre"), offset: None, category: Some(2154), sub_category: None, sort: Some(Seed), order: Some(Descending)) 2026-01-09T10:58:16.206296627Z DEBUG ygege::utils > Response status code: 302 Found 2026-01-09T10:58:16.206324896Z DEBUG ygege::search > Search response: 302 Found 2026-01-09T10:58:16.206397275Z WARN ygege::rest::search > Search failed for category 2154: Unable to find table 2026-01-09T10:58:16.206404218Z DEBUG ygege::rest::search > Returning 0 merged torrents from 1 categories 2026-01-09T10:58:16.206409364Z INFO ygege::rest::search > 0 torrents found via bulk category search
Le container a 5 heures d'ancienneté et n'est utilisé par prowlarr uniquement pour des recherches donc pas forcément toujours sollicité pendant de longues périodes.

Oui c'est un fix pour cette erreur Tesable avec cette image pierreyves258/ygege:v0.7.3

Okay le fix fonctionne car le Response status code: 302 est patché mais dans cette version j'ai l'impression que le mode turbo n'est pas pris en compte par rapport à la v0.7.2 de @UwUDev et c'est pour ça qu'il ne récupère pas le token après la demande de magnet ! Pour le moment j'utilise la v0.7.2 avec un suppression des cookies périodiquement pour ne plus faire face à cette erreur.

la 0.7.2 ou cette version ne permettent pas de bypasser le turbo, il n'y a pas de bypass possible actuellement

[Pommefrais3]

Est ce que cela aurait dû patcher ce genre d'erreur ?
2026-01-09T10:58:16.115073214Z DEBUG ygege::rest::search > Received query: categories=2154&q=Pierre&name=Pierre&sort=seed&order=desc&connarr=true 2026-01-09T10:58:16.115119587Z DEBUG ygege::rest::search > Prowlarr/Jackett detected 2026-01-09T10:58:16.115127308Z DEBUG ygege::rest::search > Performing bulk search across 1 categories: [2154] 2026-01-09T10:58:16.115134230Z DEBUG ygege::rest::search > Starting parallel search across 1 categories 2026-01-09T10:58:16.115155264Z DEBUG ygege::search > Searching for torrents (name: Some("Pierre"), offset: None, category: Some(2154), sub_category: None, sort: Some(Seed), order: Some(Descending)) 2026-01-09T10:58:16.206296627Z DEBUG ygege::utils > Response status code: 302 Found 2026-01-09T10:58:16.206324896Z DEBUG ygege::search > Search response: 302 Found 2026-01-09T10:58:16.206397275Z WARN ygege::rest::search > Search failed for category 2154: Unable to find table 2026-01-09T10:58:16.206404218Z DEBUG ygege::rest::search > Returning 0 merged torrents from 1 categories 2026-01-09T10:58:16.206409364Z INFO ygege::rest::search > 0 torrents found via bulk category search
Le container a 5 heures d'ancienneté et n'est utilisé par prowlarr uniquement pour des recherches donc pas forcément toujours sollicité pendant de longues périodes.

Oui c'est un fix pour cette erreur Tesable avec cette image pierreyves258/ygege:v0.7.3

Okay le fix fonctionne car le Response status code: 302 est patché mais dans cette version j'ai l'impression que le mode turbo n'est pas pris en compte par rapport à la v0.7.2 de @UwUDev et c'est pour ça qu'il ne récupère pas le token après la demande de magnet ! Pour le moment j'utilise la v0.7.2 avec un suppression des cookies périodiquement pour ne plus faire face à cette erreur.

la 0.7.2 ou cette version ne permettent pas de bypasser le turbo, il n'y a pas de bypass possible actuellement

C'est n'est pas vraiment un bypass si l'utilisateur a un compte Uploader par exemple.
Dans la version pierreyves258/ygege:v0.7.3, la requête se fait correctement via
Request download token https://www.yggtorrent.org/engine/start_download_timer
mais pas de réception du token Response {"token":"d9e4c9d9z9166e40dzaz150c2d77d581"}
Je me suis demandé si ce n'était pas une limite a 5 DL / jours.

Dans la v0.7.2, j'avais dans le config.json : "turbo_enabled": true

Sinon c'est peut être mon installe qui plante

[UwUDev]

Du coup, je viens de check, mais ça ne me dit pas trop comment tu as obtenu l’IP :/ (et shodan ne retourne rien)

Étant donné que ygégé ne vérifie pas les signatures, car on évite le NDD qui est protégé par CF, j’ai un peu peur que ça passe par une boîte noire avant d’atteindre ygg.

(Après, j’ai peut-être raté un message.)

[pierreyves258]

Du coup, je viens de check, mais ça ne me dit pas trop comment tu as obtenu l’IP :/ (et shodan ne retourne rien)

Étant donné que ygégé ne vérifie pas les signatures, car on évite le NDD qui est protégé par CF, j’ai un peu peur que ça passe par une boîte noire avant d’atteindre ygg.

(Après, j’ai peut-être raté un message.)

J'ai tapé yggtorrent.org dans shodan et ça m'a retourné cette IP. Actuellement en effet ça ne retourne plus rien.
Donc oui c'est une boite noire mais cette personne a réussi a bypass cloudflare et atteindre ygg (car a la fin on arrive bien sur ygg), le seul autre moyen ce serai Flaresolverr

[UwUDev]

Ouais, ça a l'air ok, des gens du Discord m'ont montré que ça a bien existé, mais l’IP est censurée maintenant (ça met un résultat, mais il n’y a rien qui s’affiche https://www.shodan.io/search?query=yggtorrent.top). Je voulais surtout m’assurer de ne pas avoir release une dinguerie.

Après, la théorie la plus probable, c’est qu’ils aient RAT un NAS/serveur d’un particulier ou d’une PME pour faire tourner le proxy dessus. Et si c’est le cas, j’en connais un·e qui aura sûrement une petite visite surprise, hélas 😔

[UwUDev]

bref comme on dit, LGTM