chore: enable Dependabot weekly GitHub Actions bumps - #2
Merged
Conversation
nicolas-rabault
force-pushed
the
chore/add-dependabot-github-actions
branch
from
June 8, 2026 11:33
07937c7 to
49280a4
Compare
MichaelMintIcecream
referenced
this pull request
in Nori-Robotics/Nori-Lab
Jul 15, 2026
Adds a 'Publish a dataset to the community' card on the marketplace page: pick one
of your promoted uploads, title + description, consent, publish. Wraps the
existing backend route (POST /nori/marketplace/datasets/{session_id}/publish,
auto-publishes after re-homing + the format gate). Handles 403 (inline
publish_public consent grant + retry) and 409 (already listed). New client fn
publishDataset. Verified end-to-end against the deployed backend.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
ZouzouWP
added a commit
to ZouzouWP/leLab
that referenced
this pull request
Jul 17, 2026
…video encoder, error visibility)
## Summary
Four independent stability fixes found while running LeLab day-to-day on
Windows with a physical SO-101 arm. None depend on each other; grouped
here only because they were all Windows/hardware crashes discovered in
the same week.
## 1. Console encoding crash (cp1252)
**Symptom:** an endpoint that logged or printed an emoji (e.g. "📡 Broadcast
thread started") could raise an unhandled `UnicodeEncodeError` on a Windows
console using the legacy `cp1252` code page, turning into an opaque 500
response with no useful message reaching the frontend.
**Fix:** `stdout`/`stderr` are reconfigured with `errors="replace"` at
import time, so unencodable characters degrade to `?` instead of crashing
the process.
## 2. Intermittent camera enumeration failure
**Symptom:** `/available-cameras` would sometimes return an empty or wrong
list, non-deterministically, depending on which FastAPI worker thread
handled the request.
**Root cause:** `pygrabber` enumerates DirectShow devices via COM, and COM
must be initialized per-thread. FastAPI serves sync endpoints from a
thread pool whose threads never call `CoInitialize`, so enumeration
silently failed on threads that hadn't done so.
**Fix:** explicitly `CoInitialize`/`CoUninitialize` around the enumeration
call in `_windows_cameras()`.
## 3. Motor-bus disconnect during recording (video encoder)
**Symptom:** recording sessions aborted mid-way with a serial
`ConnectionError` ("no status packet"), non-deterministically, on
otherwise-healthy hardware.
**Root cause:** lerobot's default RGB encoder (`libsvtav1`) is CPU-heavy
enough that two parallel encode streams (one per camera) could starve the
motor-bus read loop of CPU time, causing missed serial reads.
**Fix:** default the RGB encoder to `h264`/`ultrafast`, measured ~11x
faster to encode on this hardware, freeing enough CPU headroom that the
motor bus stays responsive.
## 4. Recording errors swallowed by a generic message
**Symptom:** when a recording session failed for *any* reason, the
frontend only ever showed "Recording session failed with error - check
logs" — the real exception (which is exactly what let us diagnose fixes
huggingface#2 and huggingface#3 above) was logged server-side but never reached the UI.
**Fix:** `/recording-status` now includes the actual exception message.
## Testing
Each of the four fixes corresponds to a crash that was reproduced and
captured in server logs before the fix landed:
- `UnicodeEncodeError` traceback from an emoji in a log line.
- Intermittent `/available-cameras` empty-list failures, thread-dependent.
- `ConnectionError: no status packet` during recording with `libsvtav1`.
- Generic "check logs" message masking the above two while debugging them.
ZouzouWP
added a commit
to ZouzouWP/leLab
that referenced
this pull request
Jul 17, 2026
…video encoder, error visibility) Four separate crashes that only show up on Windows with real hardware attached. Grouped in one PR because they were all found the same week, not because they're related — happy to split if preferred. ## 1. Console encoding crash (cp1252) **Symptom:** an emoji in a log/print line could raise an unhandled `UnicodeEncodeError` on a Windows console using the legacy cp1252 code page, turning an endpoint into a blank 500 with no useful message reaching the frontend. **Fix:** `stdout`/`stderr` are reconfigured with `errors="replace"` at import time, so unencodable characters degrade instead of crashing the process. ## 2. Camera list sometimes empty **Symptom:** `/available-cameras` would intermittently return an empty or wrong list, depending on which FastAPI worker thread handled the request. **Root cause:** `pygrabber` enumerates cameras via COM, which must be initialized per-thread. FastAPI's thread pool never did that, so enumeration silently failed on threads that hadn't. **Fix:** explicitly initialize/uninitialize COM around the enumeration call. ## 3. Recording crashes with "no status packet" **Symptom:** recording sessions aborted mid-way with a serial `ConnectionError`, non-deterministically, on otherwise-healthy hardware. **Root cause:** the default video encoder (libsvtav1) is CPU-heavy enough that two parallel encode streams could starve the motor-bus read loop of CPU time. **Fix:** default to h264/ultrafast, measured ~11x faster to encode on this hardware. ## 4. Real errors hidden behind "check logs" **Symptom:** any recording failure showed the same generic message to the user — the real exception (exactly what let us diagnose huggingface#2 and huggingface#3 above) never left the server logs. **Fix:** `/recording-status` now includes the actual exception message. ## Testing Each fix corresponds to a crash reproduced and captured in server logs beforehand, then confirmed resolved after the change.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds
.github/dependabot.ymlso this repo's pinned GitHub Action SHAsget bumped automatically once a week.
All action updates are grouped into one weekly PR (not one PR per
action) to keep the noise down, and Dependabot waits 7 days after a
release before opening the bump (cooldown). The 7-day cooldown is
aligned with the org's pinact
min_age: 7policy — so by the timethe Dependabot PR lands, the SHA is already old enough for the security
gate to accept it. The bot opens the PR; the org-wide security gate
(pinact + denylist + deny-packages + osv-scan) runs on it; a human
merges.
Why
GitHub Action SHAs that were safe when pinned can drift out of date —
missing security patches, bug fixes, or new features. Dependabot keeps
them current. Combined with the org-wide validation workflow (which
blocks compromised SHAs from landing), the bumps are safe by
construction.
Closes huggingface/tracking-issues#771