62132f503d586f5172a397772c6ca6af3e8eccfb braney Sun Sep 6 13:16:05 2026 -0700 docent: four more regression scripts, three of them watched to fail 29 scripts now, 28 of the 36 tickets that can have one. All green against genome-test. The suite's standing weakness is that almost nothing in it was ever seen to fail on a build that still had its bug, so the whole weight sits on assertion tightness. Three of these four do not have that problem. hgwbeta is running v503 and two of these fixes ship in v504, so the broken behavior was still there to be read this morning and each assertion was checked against it: rm38185 empty CGI pair. hgwbeta lands on chr7:155,799,529-155,812,871, hg38's default, because the position= after the && is silently lost; the same pair at the end returns "Mangled CGI input string &". The assertion is the position itself, since losing a variable produces no error to look for. rm38126 hub description filtering. The fixture hub is ours and deliberately malformed. Every structural check flips: on hgwbeta the chosen id, the script element and the form input are all still in the DOM, and on genome-test the id carries the descPage- prefix and the other two are gone. has:/noHas: rather than text:, because a script element's contents are not in innerText on either build -- a noText: there would have passed everywhere and asserted nothing. The two text checks deliberately do not flip: they are what stops the run passing on a page where the description simply failed to load. rm36836 a GenArk assembly and an assembly hub opened by URL. This one was only ever broken on hgwdev, so genome-test is the only server it could have been caught on. It was fixed by reverting #36835, so what the script guards is a second attempt at that work. rm38108 the caller-supplied upload address. No server left to watch it fail on: the fix is in v503_branch so hgwbeta has it, and the RR is still on v502 and so still vulnerable -- deliberately not driven there, since the reproducer's whole effect is to kill the CGI serving it. hgSession shares the fix but answers the crafted GET with the sign-in page, so it is not in the script. New fixture ~braney/docentFixtures/descFilterHub, for rm38126 only. hubCheck reports its script and form on purpose: that reporting is the other half of #38126, and the hub is not to be tidied up. refs #38252 diff --git src/hg/utils/docent/tests/regress/rm38185.docent.yaml src/hg/utils/docent/tests/regress/rm38185.docent.yaml new file mode 100644 index 00000000000..772e3c20b82 --- /dev/null +++ src/hg/utils/docent/tests/regress/rm38185.docent.yaml @@ -0,0 +1,48 @@ +# #38185 -- an empty CGI pair (&&) in the middle of a query string ate the next variable. +# +# cgiParseInputAbort() took the text after a value, did `strchr(dataPt, '&')` and +# terminated there, leaving the pointer on the SECOND ampersand. The next pass through the +# loop therefore read the following variable's name as `&position`, stored it under a name +# nobody looks up, and lost it with no warning at all. The same empty pair at the END of +# the query string took the other branch and aborted instead: +# +# Very Early Error +# Mangled CGI input string & +# +# So one empty pair was silent in one position and fatal in the other. Both parsers in +# lib/cheapcgi.c now skip an empty pair. QA Ready, target 504. +# +# This is not hypothetical. It is what broke the reporter's link in #38145: his URL had && +# immediately before hgS_doLoadUrl, his saved session never loaded, and he reported it as +# missing tracks, which sent us looking in the wrong place for days. +# +# Both checks were WATCHED TO FAIL, which almost nothing else in this suite can say. The +# fix is on master for v504, so hgwbeta was still running the broken parser on 2026-09-06 +# and both URLs were driven there: +# +# middle hgwbeta lands on chr7:155,799,529-155,812,871, hg38's default position -- +# the position the URL asked for was simply gone +# trailing hgwbeta returns "Mangled CGI input string &" +# +# That is why the first assertion is the POSITION ITSELF rather than the absence of an +# error: losing the variable produced no error to look for. The string comes from the +# #positionDisplay span, which is real page text, not the title, so expect: text can see it. +# +# The two steps deliberately ask for DIFFERENT positions. After the first step the cart +# holds chr1:1-1,000, so a second step asking for the same place would be satisfied by the +# cart whether or not the URL was parsed. +target: genome-test +db: hg38 +reset: true +fast: true +steps: + # Empty pair in the MIDDLE: position= used to be swallowed. + - goto: "/cgi-bin/hgTracks?db=hg38&&position=chr1:1-1000&pix=1100" + - expect: {rows: [ruler], text: "chr1:1-1,000"} + + # The same empty pair at the END, which used to abort before any of it was read. + - goto: "/cgi-bin/hgTracks?db=hg38&position=chr3:1-1000&pix=1100&&" + - expect: + rows: [ruler] + text: "chr3:1-1,000" + noText: "Mangled CGI input string"