Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Hosted rollback rewrites uv pylock.toml `upload-time` with milliseconds, so the restored file never matches what uv writes

Ouverte Adaptée aux débutants
  • Quelque chose ne va pas ?
#408 1 commentaire 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
78/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
rust
Domaine
cli

Piste de recherche

Commencez dans crates/socket-patch-core/src/patch/redirect/upstream/uv.rs, dans upload_time() vers la ligne 394 et dans la branche shape.datetime vers les lignes 424-433. Comparez le formatage de pylock.toml avec les formats de lock correspondants, puis reproduisez le flux de hosted scan et de rollback et comparez par diff le fichier restauré avec son original. C’est terminé lorsque les valeurs de temps d’upload de pylock utilisent une précision à la seconde entière et que le rollback ne laisse aucun diff parasite.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

agent:triaged bug bughunt pm:uv priority:p1

[agent] Found by the scheduled uv bug-hunt routine (ledger #310).

Summary

After a hosted scan and then rollback (or remove), a uv-written PEP 751 pylock.toml doesn't come back as uv wrote it. The restored sdist / wheels entries carry upload-time with milliseconds (2021-05-05T14:18:17.237Z). uv writes pylock upload-time as a TOML datetime truncated to whole seconds (2021-05-05T14:18:17Z), and so do the lock's own untouched sibling entries. Every rolled-back pylock is left with a spurious diff that no uv command would produce.

The upstream restore formats upload-time with uv.lock's millisecond rule (upload_time() in crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:394) for both lock kinds. For pylock it only switches the quoting (shape.datetime, :424-433), not the precision.

Impact

This is low severity: the restored file is valid and installs the pristine wheel (uv pip sync pylock.toml → original six.py). But "rollback" doesn't return the file to its pre-patch bytes. A repo that regenerates pylock.toml in CI (uv export --format pylock.toml) and checks git diff --exit-code fails after an otherwise clean rollback, and the leftover diff looks like a Socket edit that was never undone. The uv.lock and requirements.txt restores in the same run are byte-identical, so the gap is pylock-specific.

Repro (Linux)

Mock patch API as in #379 / #381, with --patch-server-url for the mock origin and the PyPI JSON API reachable.

SP="socket-patch --api-url http://127.0.0.1:18080 --api-token t --org test-org --patch-server-url http://127.0.0.1:18080"
mkdir p && cd p
printf '[project]\nname = "uvp"\nversion = "0.1.0"\nrequires-python = ">=3.9"\ndependencies = ["six==1.16.0", "idna==3.7"]\n' > pyproject.toml
uv lock && uv export --format pylock.toml -o pylock.toml
cp pylock.toml pylock.orig
$SP scan --mode hosted --json --yes   # rewrittenFiles includes pylock.toml
$SP rollback --json --yes             # success, hosted.reverted [pkg:pypi/[email protected]]
diff pylock.orig pylock.toml
# < sdist = { url = ".../six-1.16.0.tar.gz", upload-time = 2021-05-05T14:18:18Z, size = 34041, ... }
# > sdist = { url = ".../six-1.16.0.tar.gz", upload-time = 2021-05-05T14:18:18.379Z, size = 34041, ... }
# < wheels = [{ url = ".../six-1.16.0-py2.py3-none-any.whl", upload-time = 2021-05-05T14:18:17Z, ... }]
# > wheels = [{ url = ".../six-1.16.0-py2.py3-none-any.whl", upload-time = 2021-05-05T14:18:17.237Z, ... }]

The same diff appears when pylock.toml sits next to uv.lock and an exported requirements.txt (those two restore byte-identically). uv 0.8.17, uv 0.12.21, and uv pip compile --format pylock.toml all write upload-time = 2021-05-05T14:18:17Z for that wheel.

Expected vs actual

  • Expected: CLI_CONTRACT.md, "Hosted unwind coverage": rollback restores each hosted pin "to its default upstream registry entry", with the artifact fields in the shape "the lock's other registry packages" show. Here the siblings show second precision, and uv only ever writes that precision in pylock files. The restored entry should be what uv would write, as it already is for uv.lock.
  • Actual: millisecond upload-time values in the restored pylock entry.

OS × uv matrix (main 2463257)

OS uv 0.8.17 uv 0.12.21
Linux fail fail (reproduced 2×)

macOS and Windows weren't probed. The defect is in platform-independent string formatting.

First bad

2463257 (#277, v5 upstream restore). Release 4.0.0 restored pylock from a recorded fragment.

Suspect code

crates/socket-patch-core/src/patch/redirect/upstream/uv.rs:394 (upload_time, millisecond rule) and :424-433 (the shape.datetime branch, which should truncate to seconds for pylock, or follow the siblings' precision).

Related: #407 (a uv pip compile pylock can't be rolled back at all).

Langage dominant
Rust
Étoiles
8
Forks
0
Merge moyen
18 h 4 min
PR mergées (30 j)
70

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de SocketDev/socket-patch

Toutes les issues de SocketDev/socket-patch

Issues similaires

Plus d'issues Rust

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.