ci: refresh fetchall baseline for bridge_api.py additions#7891
Merged
Conversation
The fetchall guard test was failing because scripts/baselines/fetchall_existing.txt was stale. Two commits added new .fetchall() calls to node/bridge_api.py without updating the baseline: - 7925fe1 (bridge: account deposit locks against the source balance at create) added migrate_deposits_to_hard_locks(), which fetches rows filtered on status IN ('pending','locked','confirming') AND source_debited = 0. This is a one-time startup migration over the active in-flight deposit set, not an unbounded scan. - 7f3ffd0 (bridge: deposit-create honors in-flight reservations (encumbrance-aware)) added list_bridge_transfers(), which fetches rows with a query that always has LIMIT bound to min(limit, 500). Also bounded. Regenerated the baseline the way the guard script itself documents, via bash scripts/check_fetchall.sh --print-baseline > scripts/baselines/fetchall_existing.txt No code was touched and no calls were annotated. The rest of the diff is pure reordering from the script's own sort output, not content changes (net +2 lines, matching the two new bridge_api.py calls). Neither new call looks like the unbounded-query pattern the guard exists to catch (issue #6627), so I did not add fetchall-ok annotations or otherwise touch node/bridge_api.py. If we want to be stricter, both are reasonable candidates for a follow-up annotation (already-paginated for the LIMIT query, bounded-by-schema for the status-filtered migration). Signed-off-by: Scott <scottbphone12@gmail.com>
github-actions
Bot
added
BCOS-L1
Contributor
RTC RewardThis merged PR earned 5 RTC — sent to |
Contributor
|
| Metric | Value |
|---|---|
| Trust Score | 48/100 |
| Certificate ID | BCOS-ad6813f3 |
| Tier | L1 (not met) |
What does this mean?
The BCOS (Beacon Certified Open Source) engine scans for:
- SPDX license header compliance
- Known CVE vulnerabilities (OSV database)
- Static analysis findings (Semgrep)
- SBOM completeness
- Dependency freshness
- Test infrastructure evidence
- Review attestation tier
BCOS v2 Engine - Free & Open Source (MIT) - Elyan Labs
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
2 participants
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
The
testjob was red becausetests/test_fetchall_guard.py::test_fetchall_guard_passes_current_baselinewas failing. The baseline filescripts/baselines/fetchall_existing.txthad gone stale: two commits added new.fetchall()calls tonode/bridge_api.pywithout updating it.7925fe174(bridge: account deposit locks against the source balance at create) addedmigrate_deposits_to_hard_locks(), which fetches rows filtered onstatus IN ('pending','locked','confirming') AND source_debited = 0. One-time startup migration over the active in-flight deposit set, not an unbounded scan.7f3ffd02f(bridge: deposit-create honors in-flight reservations (encumbrance-aware)) addedlist_bridge_transfers(), which always hasLIMITbound tomin(limit, 500). Also bounded.I regenerated the baseline the way
scripts/check_fetchall.shitself documents (its own stale-baseline error message says to do this):No production code was touched, and no calls were annotated with
fetchall-ok. The rest of the diff beyond the 2 new lines is pure reordering from the script's own sort output (locale-dependent), not a content change; net +2 lines matching the two new bridge_api.py calls exactly.Risk assessment
Neither new call looks like the unbounded-query pattern the guard exists to catch (issue #6627):
list_bridge_transfersis capped at 500 rows viaLIMIT.migrate_deposits_to_hard_locksis bounded by a status filter to the currently-active deposit set, and only runs once at migration/init time.Both are reasonable candidates for a follow-up PR that adds explicit
# fetchall-ok: already-paginated/# fetchall-ok: bounded-by-schemaannotations, but I did not do that here since the ask was specifically to refresh the baseline, not touchnode/bridge_api.py.Test plan
python -m pytest tests/test_fetchall_guard.py -x -v— all 11 tests passbash scripts/check_fetchall.sh— printsOK: no new unannotated .fetchall() calls in node/.--print-baselineoutput against old baseline; only the two new bridge_api.py lines were added, everything else was line reordering)