bb27fdc2f612380ae05efcd1959b4b26297738e5 braney Wed Sep 9 13:16:38 2026 -0700 docent: an xfail for #38310, and the second script that needs pixels A hub track whose `type bigBed N` declares more fields than the file holds drew its row with no items in it. The fix is written and verified but is not on master, so no server passes this today. That is the only reason it is an .xfail: `make test` fails if an xfail passes, so the day the fix reaches genome-test the suite says there is a test waiting. The ticket says the row came up empty "with no warning". The row is empty, but there is a message. hgTracks catches the abort into networkErrMsg and swaps in bigDrawWarning, which paints the row as a pale yellow bar, 240,240,180 (undefinedYellowColor, hg/hgTracks/simpleTracks.c), with the text inside it. The text read `invalid signed integer: ""`, the fourth field of a four-field row array that was never filled in. So the message was there, said nothing useful, and is drawn INSIDE the png, which is why every text check in this suite is blind to it and why the original measurement, counting item map boxes in the HTML, reported silence. That is why the assertion is a color check, the second one here after rm36212. Each row is asked for the color it is drawn in: fixed gives a black item box and a black pack label, dominant 0,0,0; broken gives a full-width bigWarn bar, dominant 240,240,180. `is: "0,0,0"` states the item is there and `not: "240,240,180"` states the warning bar is not. `rows:` cannot express this, because the broken build draws all eight rows. The second half of the same bug is on the details page: hgc took the declared count too and aborted, so an item that did draw could not be clicked through. That is live on the RR today for hg38 setDups and two hg19 exomeProbesets subtracks, all `bigBed 4` over a three-field file. The step clicks an item and asserts the item's POSITION, because the aborted page carries the track's longLabel twice in its own header and a text: check on that alone passes on it. It clicks bb9 rather than bb12, since "type bigBed 12" is a prefix of "type bigBed 12 +". Do not add a mouseover: step here. Before docent's e2b5b26b925, itemXY handed a track with no box of its own a neighbour's box, so a tooltip check reported uc.1 for rows that drew nothing. Measured both ways on 2026-09-09. Against genome-test it fails at the color step naming all five over-declared rows, each 240,240,180 at 95% of the row; against the #38310 sandbox all eight are 0,0,0 at 100% and the run exits 0. Then the whole directory was run against that sandbox twice, once with the patched hgTracks and hgc and once with unpatched controls built from the same tree: thirty-seven scripts, identical verdicts, except this one. Notes in /hive/groups/browser/redmineNotes/38310/claude/. The fixture is ours, at ~/public_html/docentFixtures/bigBedFieldCount/. One bigBed with four fields, eight tracks over it, one declared type each, so the only thing that differs between the rows is the number on the type line. hubCheck rejects five of the eight, correctly; it is the empty row that is the bug, not the hub. README.txt gains the section, and with it two rules that apply to any script here: `rows:` cannot express "this track drew its items", and a drawn item that cannot be clicked through is half a bug. refs #38310, refs #38252 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> diff --git src/hg/utils/docent/tests/regress/README.txt src/hg/utils/docent/tests/regress/README.txt index 5f89124f58b..60e45b9c2e5 100644 --- src/hg/utils/docent/tests/regress/README.txt +++ src/hg/utils/docent/tests/regress/README.txt @@ -1,63 +1,87 @@ Docent regression tests ----------------------- One script per fixed bug, named for its ticket. Run by hand: make test # every *.docent.yaml here make test T=rm36382 # just one The candidate list this directory is being built from, with the recipe and assertion worked out for each ticket, is at /hive/groups/browser/redmineNotes/37892/claude/2026-09-04_1100_regression_candidates.md What these are, and what they are not ------------------------------------- Each script asserts the behavior the ticket says is correct, on genome-test. None of them was run against a build that still had the bug, so none has been seen to fail for the reason it exists. That is a deliberate choice about cost, and it puts the whole weight on how tight the assertion is: * name the error string the ticket quoted in `noText:`, not a generic "Error" * prefer `rows: [...] exact: true` and `noRows:` over a bare `rows:` * a test that only checks a row is PRESENT usually passes on the buggy build too, because the bug was an extra row, a wrong label, or a bad tooltip Three things will rot these tests --------------------------------- Most recipes start from the saved session named in the ticket, because that is the cheapest way to reach the exact state. A session that is deleted does not fail loudly: hgTracks serves a page saying it could not find it, and every `noText:` check on that page passes. So a session-based test also asserts something that is only true when the session really loaded. Six recipes need a test hub on a colleague's public_html. Same problem, same remedy. Fixtures we own live in ~/public_html/docentFixtures/, and `make preflight` checks that every hub a script here names still answers. Copy a reporter's hub in there rather than loading theirs, so nothing outside this repository can change what a test measures. A fixture hub must never name a track anything the assembly might also call it. A track name resolves to `img_data_<name>` first and only then to a hub row's `hub_<n>_<name>`, so an exact native id wins: the hub row is on the page, and every `track:`, `mouseover:` and `rows:` in the script reads the NATIVE row instead. Nothing warns. rm35920's fixture called its track `ultras`, hg38 has its own `ultras`, and that script asserted a tooltip off the native data for as long as it existed -- it looked green and tested nothing. Prefix a fixture's track names with the ticket number. rm36212 is the one to read before writing another -------------------------------------------------- It is the only script here that has been watched to fail on a build with the bug AND to pass on a build with the fix, which is the evidence every other script in this directory would like to have and does not. The recipe: build the fix into a ticket sandbox, point a copy of the script at that port with `target: http://127.0.0.1:PORT/cgi-bin`, and record in the comment which checks flipped. It costs one build and it settles what a tight assertion can only argue. It is also the first script to assert a COLOR, using `expect: {color: ...}`, because it is the first bug here that leaves the page identical -- same rows, same height, same item names, same tooltips. When rows:, height:, text: and has: are all blind to a bug, the pixels are what is left. See tests/colorchecks.docent.yaml for the check itself. + +rm38310 is the second color check, and the second script watched both ways +--------------------------------------------------------------------------- + +Same recipe as rm36212, and worth reading for the reason it needs pixels, which is +different. Its bug does not draw the wrong color; it replaces the row with the bigWarn +bar, 240,240,180 (undefinedYellowColor, hg/hgTracks/simpleTracks.c), and paints an error +message INSIDE the png. So the row is still drawn, still the same name, and every text +check on the page passes -- the message is in the image, where noText: cannot reach it. +That is also why the ticket was filed saying there was no warning at all. + +Two things fall out of it that apply to any script here: + + * `rows:` cannot express "this track drew its items". The broken build draws the row. + `color:` with `is:` on the item color and `not: "240,240,180"` can, and a failure + prints what each row really came out. + * A drawn item that cannot be clicked through is half a bug. rm38310 clicks its item + and asserts the item's POSITION on the hgc page, because the aborted hgc page carries + the track's longLabel twice in its own header and a text: check on that alone passes + on it. + +Measured both ways on 2026-09-09: the whole directory was run against the #38310 ticket +sandbox twice, once with the patched hgTracks and hgc and once with unpatched controls +built from the same tree. Thirty-seven scripts, identical verdicts, except this one.