Repository navigation
Boards: list a report's public dump, count its private ones; a pinout is not always UART - #538
Conversation
… is not always UART The catalogue's "factory flash dumps" counted only the OpenHisiIpCam archive's 11: an owner report's backup never reached its board, shared or not. - A dump its sender shared publicly is a flash_dump of the report's unit, listed at its report's address (board_artifacts.href) and never copied under BOARDS_ROOT: the report serves it no-store, so making it private takes it down at once, which a copy cached for a month under /board-files/ would not. - A dump not served -- kept private by its sender or by a reviewer -- is counted on its unit (board_units.private_dumps, migration 044); the API sums it per board (coverage.private_dumps) and the stats line says how many more a maintainer has. - "with UART pinout" counted every pinout, connector diagrams included (the vendors' interface drawings name no UART): it now says "with a pinout", in the lede too.
PR Summary by QodoList public report dumps on boards and count private backups
AI Description
Diagram
High-Level Assessment
Files changed (22)
|
Code Review by Qodo
1.
|
Qodo's review of #538: a report published on two boards is a unit on each, carrying its dumps, so summing the boards' coverage counted them twice. The tree now says its totals itself -- distinct served dumps by sha256, and a report's private ones once per report (by the receipt in its units' reference) -- and the stats line uses them; each board keeps its own coverage.
#540) * Web role: refresh the published reports' board units in the background The web role refreshed every published report's board unit before it listened. A change that makes each unit new -- #538 gave them a private-dump count -- rewrites all of them on the first start, which took production past openipc-deploy's 90-second /up gate twice; it rolled back, dev having too few reports to show it. The refresh now starts once the routes are up, in the background, and the role's stop waits for it before giving up the web lock. A refresh cut short by a stop is finished by the next start: a unit whose files are missing is rewritten. * Board units: read the reports under the lock, stage a rewrite, bound the shutdown wait Qodo's review of #540, now that the startup refresh runs while the site serves: - the published reports are read once the apply's lock is held (RefreshReportUnits), so a refresh started first cannot apply a list older than a later review's and put a report rejected meanwhile back on its board; - a unit's rewrite stages its files under Root/.staging and swaps them in after its rows commit, so no page links a file not yet there, and a rewrite cut short leaves the unit as it was; - the web role's stop waits ten seconds for the refresh, not forever: one queued behind a review's waits on a mutex that does not watch the context.
The web role refreshed every published report's board unit before it listened. A change that makes each unit new -- #538 gave them a private-dump count -- rewrites all of them on the first start, which took production past openipc-deploy's 90-second /up gate twice; it rolled back, dev having too few reports to show it. The refresh now starts once the routes are up, in the background, and the role's stop waits for it before giving up the web lock. A refresh cut short by a stop is finished by the next start: a unit whose files are missing is rewritten.
On
/cameras/boardsthe stats line counted 11 factory flash dumps. That is only the OpenHisiIpCam archive: no owner report's backup has ever reached its board. Published reports hold 45 backups: 36 kept private by their senders, 5 shared but made private by a reviewer, and 4 public.Dumps
flash_dumpfile of the report's board unit. It is listed at the report's own address (board_artifacts.href) and never copied underBOARDS_ROOT. The report serves itno-store, so a reviewer making it private takes it down at once. A copy under/board-files/is cached for a month, through the mirrors too, and would not come down.board_units.private_dumps, migration 044. The API sums it per board ascoverage.private_dumps, and the stats line adds "N more kept private, for maintainers".PublishedTextsnow also returns a published report that has only a private dump, so its count isn't lost.Pinouts
interfacedrawings show VGA, HDMI and SATA, and cctvsp labels power, Ethernet and RS485. Neither names a UART. The files carry no text that could tell them apart, so the label now says "with a pinout" (en, ru, zh), and so does the catalogue lede.The other numbers were checked against the database and are right: 1,397 boards, 349 devices, 29 named makers, and 919 boards still needing a pinout.
Tests
TestAReportsDumpIsLinkedNotCopiedAndItsPrivateOnesAreCounted: the dump is linked on both boards of a report and not on disk, the private count shows in coverage, a second refresh rewrites nothing, and making the dump private unlists and counts it.TestAPublishedReportsDumpIsLinkedOrCounted: a public dump comes back as a link, a private one as a count, and a reviewer's private decision moves it from the first to the second.statstest.service/run.sh testpasses in full; frontend lint, typecheck and tests pass.Note for the Ruision donor work: its uncommitted
044_board_ruision.sqlmust become 045 if this lands first.