File Changes for braney

v502_preview to v502_preview2 (2026-07-27 to 2026-08-04) v502

• src/hg/hgConvert/hgConvert.c
  • lines changed 11, context: html, text, full: html, text
    fbfdc0a36bb6d3b0eb57dd07262c059086c7054e Fri Jul 31 14:55:15 2026 -0700
    hgConvert: link to the alignment request page, behind showLiftRequest, refs #37973 The Convert page's assembly list only offers targets that already have a chain from the source, so it is where a user finds out theirs is missing. Nothing in the tree linked to liftRequest.html, the page that requests a new alignment, so unless someone wrote to us and we sent the URL they were unlikely to find it. Adds "Target assembly not listed? Request an alignment" at the foot of the Destination section, gated by the new hg.conf flag showLiftRequest, which defaults FALSE. Registered in the hg.conf catalog as a release gate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 5, context: html, text, full: html, text
    2bc6a4a8c77bc5ea8fec9a1661e9526b5f1735d7 Mon Aug 3 14:54:39 2026 -0700
    Keep hgConvert's "Hide all default tracks on the target" checked by default across a target assembly change. The checkbox is disabled by JS while QuickLift is off, which is the default state. A disabled checkbox is not submitted but its boolshad shadow variable still is, so changing the target genome or assembly resubmitted the form and stored hideTracksOnConvert=0 in the cart, leaving the box unchecked on redraw. Disable the shadow along with the checkbox so the default survives.
• src/hg/hgTracks/decorator.c
  • lines changed 2, context: html, text, full: html, text
    304e9ab6e3a62d7863b144478fc1ac621623a617 Wed Jul 29 11:42:01 2026 -0700
    Fix data race on the chromAlias caches that was crashing hgTracks in parallel decorator loads. chromAliasFindNative() and chromAliasFindAliases() lazily created their static cache hashes and did their first lookup outside the mutex, taking the lock only for the miss path. hgTracks loads decorators on real pthreads, so two threads arriving before a cache existed could race on it and SIGSEGV in hashLookup. Move the lock above the lazy init and the first lookup so the whole cache access is inside it. Both paths of chromAliasFindNative() now return an allocated string rather than the cache-owned pointer, so document that the caller owns the result, free it in decorationNativeItem() (called once per decoration), and drop the redundant outer cloneString() in hgOfficialChromName(). refs #37955
• src/hg/hgTracks/encode.c
  • lines changed 1, context: html, text, full: html, text
    80daf93864f5609f6b7695766a78edd90cac0c1d Fri Jul 31 12:29:05 2026 -0700
    quickLift: accept broadPeak tracks, and make lifted peak details right. refs #37970 Add broadPeak to the types validateOneTdb will lift; hgTracks already knew how to load one. Make hgc's encodePeak handler read the table out of the source assembly and lift the items, instead of looking in the destination assembly where the table does not exist and coming up empty. Lift peaks with a new quickLiftPeaks() rather than casting them to bed and calling quickLiftBeds(), whose thickStart and thickEnd assignments land on signalValue and pValue in struct encodePeak.
• src/hg/hgTracks/hgTracks.c
  • lines changed 11, context: html, text, full: html, text
    644f1ed70c1b04896944f66bdfa03c16278135d6 Fri Jul 31 15:16:12 2026 -0700
    quickLift: keep the difference lines from standing still during a drag The difference lines are drawn up over a track's center label, but center labels don't scroll with the data, so the lines sat still while the image moved underneath them. hgTracks now keeps each center label as text with the color it was drawn in, and flags the label when lines were painted over it. While the image is being dragged hgTracks.js hides that slice and puts the label up as text in its place, then swaps the image back on drop. Windows with no difference lines drawn are untouched. refs #37974
• src/hg/hgTracks/imageV2.c
  • lines changed 22, context: html, text, full: html, text
    644f1ed70c1b04896944f66bdfa03c16278135d6 Fri Jul 31 15:16:12 2026 -0700
    quickLift: keep the difference lines from standing still during a drag The difference lines are drawn up over a track's center label, but center labels don't scroll with the data, so the lines sat still while the image moved underneath them. hgTracks now keeps each center label as text with the color it was drawn in, and flags the label when lines were painted over it. While the image is being dragged hgTracks.js hides that slice and puts the label up as text in its place, then swaps the image back on drop. Windows with no difference lines drawn are untouched. refs #37974
• src/hg/hgTracks/imageV2.h
  • lines changed 6, context: html, text, full: html, text
    644f1ed70c1b04896944f66bdfa03c16278135d6 Fri Jul 31 15:16:12 2026 -0700
    quickLift: keep the difference lines from standing still during a drag The difference lines are drawn up over a track's center label, but center labels don't scroll with the data, so the lines sat still while the image moved underneath them. hgTracks now keeps each center label as text with the color it was drawn in, and flags the label when lines were painted over it. While the image is being dragged hgTracks.js hides that slice and puts the label up as text in its place, then swaps the image back on drop. Windows with no difference lines drawn are untouched. refs #37974
• src/hg/hgTracks/quickLift.c
  • lines changed 15, context: html, text, full: html, text
    e55631175ec686f6f63bc4da3ab3b0972c8e0ef3 Tue Jul 28 10:18:23 2026 -0700
    quickLift: leave the Alignment Differences track blank when there are no differences drawDenseChain() was only reached when the window had no mismatches, indels, or double-sided gaps, and it painted each chain as a solid box from a rotating palette, so an identical window rendered as solid blue. Renamed it mapDenseChain() and dropped the fill (and the now-unused palette); it still lays down a mapbox per chain so the click-through to the other assembly keeps working.
  • lines changed 7, context: html, text, full: html, text
    644f1ed70c1b04896944f66bdfa03c16278135d6 Fri Jul 31 15:16:12 2026 -0700
    quickLift: keep the difference lines from standing still during a drag The difference lines are drawn up over a track's center label, but center labels don't scroll with the data, so the lines sat still while the image moved underneath them. hgTracks now keeps each center label as text with the color it was drawn in, and flags the label when lines were painted over it. While the image is being dragged hgTracks.js hides that slice and puts the label up as text in its place, then swaps the image back on drop. Windows with no difference lines drawn are untouched. refs #37974
• src/hg/hgc/encodeClick.c
  • lines changed 78, context: html, text, full: html, text
    80daf93864f5609f6b7695766a78edd90cac0c1d Fri Jul 31 12:29:05 2026 -0700
    quickLift: accept broadPeak tracks, and make lifted peak details right. refs #37970 Add broadPeak to the types validateOneTdb will lift; hgTracks already knew how to load one. Make hgc's encodePeak handler read the table out of the source assembly and lift the items, instead of looking in the destination assembly where the table does not exist and coming up empty. Lift peaks with a new quickLiftPeaks() rather than casting them to bed and calling quickLiftBeds(), whose thickStart and thickEnd assignments land on signalValue and pValue in struct encodePeak.
• src/hg/inc/chromAlias.h
  • lines changed 2, context: html, text, full: html, text
    304e9ab6e3a62d7863b144478fc1ac621623a617 Wed Jul 29 11:42:01 2026 -0700
    Fix data race on the chromAlias caches that was crashing hgTracks in parallel decorator loads. chromAliasFindNative() and chromAliasFindAliases() lazily created their static cache hashes and did their first lookup outside the mutex, taking the lock only for the miss path. hgTracks loads decorators on real pthreads, so two threads arriving before a cache existed could race on it and SIGSEGV in hashLookup. Move the lock above the lazy init and the first lookup so the whole cache access is inside it. Both paths of chromAliasFindNative() now return an allocated string rather than the cache-owned pointer, so document that the caller owns the result, free it in decorationNativeItem() (called once per decoration), and drop the redundant outer cloneString() in hgOfficialChromName(). refs #37955
• src/hg/inc/quickLift.h
  • lines changed 5, context: html, text, full: html, text
    80daf93864f5609f6b7695766a78edd90cac0c1d Fri Jul 31 12:29:05 2026 -0700
    quickLift: accept broadPeak tracks, and make lifted peak details right. refs #37970 Add broadPeak to the types validateOneTdb will lift; hgTracks already knew how to load one. Make hgc's encodePeak handler read the table out of the source assembly and lift the items, instead of looking in the destination assembly where the table does not exist and coming up empty. Lift peaks with a new quickLiftPeaks() rather than casting them to bed and calling quickLiftBeds(), whose thickStart and thickEnd assignments land on signalValue and pValue in struct encodePeak.
• src/hg/js/hgTracks.js
  • lines changed 30, context: html, text, full: html, text
    644f1ed70c1b04896944f66bdfa03c16278135d6 Fri Jul 31 15:16:12 2026 -0700
    quickLift: keep the difference lines from standing still during a drag The difference lines are drawn up over a track's center label, but center labels don't scroll with the data, so the lines sat still while the image moved underneath them. hgTracks now keeps each center label as text with the color it was drawn in, and flags the label when lines were painted over it. While the image is being dragged hgTracks.js hides that slice and puts the label up as text in its place, then swaps the image back on drop. Windows with no difference lines drawn are untouched. refs #37974
• src/hg/lib/chromAlias.c
  • lines changed 14, context: html, text, full: html, text
    304e9ab6e3a62d7863b144478fc1ac621623a617 Wed Jul 29 11:42:01 2026 -0700
    Fix data race on the chromAlias caches that was crashing hgTracks in parallel decorator loads. chromAliasFindNative() and chromAliasFindAliases() lazily created their static cache hashes and did their first lookup outside the mutex, taking the lock only for the miss path. hgTracks loads decorators on real pthreads, so two threads arriving before a cache existed could race on it and SIGSEGV in hashLookup. Move the lock above the lazy init and the first lookup so the whole cache access is inside it. Both paths of chromAliasFindNative() now return an allocated string rather than the cache-owned pointer, so document that the caller owns the result, free it in decorationNativeItem() (called once per decoration), and drop the redundant outer cloneString() in hgOfficialChromName(). refs #37955
• src/hg/lib/hdb.c
  • lines changed 1, context: html, text, full: html, text
    304e9ab6e3a62d7863b144478fc1ac621623a617 Wed Jul 29 11:42:01 2026 -0700
    Fix data race on the chromAlias caches that was crashing hgTracks in parallel decorator loads. chromAliasFindNative() and chromAliasFindAliases() lazily created their static cache hashes and did their first lookup outside the mutex, taking the lock only for the miss path. hgTracks loads decorators on real pthreads, so two threads arriving before a cache existed could race on it and SIGSEGV in hashLookup. Move the lock above the lazy init and the first lookup so the whole cache access is inside it. Both paths of chromAliasFindNative() now return an allocated string rather than the cache-owned pointer, so document that the caller owns the result, free it in decorationNativeItem() (called once per decoration), and drop the redundant outer cloneString() in hgOfficialChromName(). refs #37955
• src/hg/lib/quickLift.c
  • lines changed 25, context: html, text, full: html, text
    80daf93864f5609f6b7695766a78edd90cac0c1d Fri Jul 31 12:29:05 2026 -0700
    quickLift: accept broadPeak tracks, and make lifted peak details right. refs #37970 Add broadPeak to the types validateOneTdb will lift; hgTracks already knew how to load one. Make hgc's encodePeak handler read the table out of the source assembly and lift the items, instead of looking in the destination assembly where the table does not exist and coming up empty. Lift peaks with a new quickLiftPeaks() rather than casting them to bed and calling quickLiftBeds(), whose thickStart and thickEnd assignments land on signalValue and pValue in struct encodePeak.
• src/hg/lib/trackHub.c
  • lines changed 14, context: html, text, full: html, text
    59dff194de2f867c3a8d3daaacace8d59dc7775b Fri Jul 31 12:26:14 2026 -0700
    quickLift: match trackDb types without regard to case, so 'type bigbed' is accepted
  • lines changed 1, context: html, text, full: html, text
    80daf93864f5609f6b7695766a78edd90cac0c1d Fri Jul 31 12:29:05 2026 -0700
    quickLift: accept broadPeak tracks, and make lifted peak details right. refs #37970 Add broadPeak to the types validateOneTdb will lift; hgTracks already knew how to load one. Make hgc's encodePeak handler read the table out of the source assembly and lift the items, instead of looking in the destination assembly where the table does not exist and coming up empty. Lift peaks with a new quickLiftPeaks() rather than casting them to bed and calling quickLiftBeds(), whose thickStart and thickEnd assignments land on signalValue and pValue in struct encodePeak.
• src/hg/utils/cartTrackVarCatalog/cartTrackVarCatalog.py
  • lines changed 301, context: html, text, full: html, text
    6c9c79a4bb5af45d213d8ba5fc373ed0a6181dca Sat Aug 1 12:05:30 2026 -0700
    cartTrackVarCatalog: add a --reconcile that reads the tree refs #37838 --check only read the catalog itself, verifying that every family a type names exists, so a track-scoped cart variable added tomorrow was invisible to it. It never called the harvester at all. Adds --reconcile, which does: it compares what harvestCartVars finds against the catalog and reports a name in neither the catalog nor cartVarsNotCataloged.txt, silent and exit 0 otherwise, so it can run nightly. --update-baseline accepts new names as a reviewable diff. Matching is on the name with its leading separator stripped, because the harvester cannot always tell which separator a name is used with: the fourth argument of cart*ClosestToHome is a bare suffix while a safef("%s.%s") site carries the dot. A wildcard entry also registers its trailing component, since the harvester sees decorator.<name>.blockMode only as blockMode. Without that nine already-cataloged names read as new. Sixty-seven names are left in the baseline, and about fifteen of them look like real cart variables that were never cataloged, among them FilterLabel, FilterValuesDefault, HighlightType, minAc, fileSortOrder and the tablesTables paging vars. Cataloging those needs a read of the UI code and is not done here. harvestCartVars grows a harvest() entry point so the scan has one definition rather than one in main and a second written out by hand; --by-var output is unchanged.
• src/hg/utils/cartTrackVarCatalog/cartVarsNotCataloged.txt
  • lines changed 89, context: html, text, full: html, text
    6c9c79a4bb5af45d213d8ba5fc373ed0a6181dca Sat Aug 1 12:05:30 2026 -0700
    cartTrackVarCatalog: add a --reconcile that reads the tree refs #37838 --check only read the catalog itself, verifying that every family a type names exists, so a track-scoped cart variable added tomorrow was invisible to it. It never called the harvester at all. Adds --reconcile, which does: it compares what harvestCartVars finds against the catalog and reports a name in neither the catalog nor cartVarsNotCataloged.txt, silent and exit 0 otherwise, so it can run nightly. --update-baseline accepts new names as a reviewable diff. Matching is on the name with its leading separator stripped, because the harvester cannot always tell which separator a name is used with: the fourth argument of cart*ClosestToHome is a bare suffix while a safef("%s.%s") site carries the dot. A wildcard entry also registers its trailing component, since the harvester sees decorator.<name>.blockMode only as blockMode. Without that nine already-cataloged names read as new. Sixty-seven names are left in the baseline, and about fifteen of them look like real cart variables that were never cataloged, among them FilterLabel, FilterValuesDefault, HighlightType, minAc, fileSortOrder and the tablesTables paging vars. Cataloging those needs a read of the UI code and is not done here. harvestCartVars grows a harvest() entry point so the scan has one definition rather than one in main and a second written out by hand; --by-var output is unchanged.
• src/hg/utils/cartTrackVarCatalog/harvestCartVars.py
  • lines changed 70, context: html, text, full: html, text
    6c9c79a4bb5af45d213d8ba5fc373ed0a6181dca Sat Aug 1 12:05:30 2026 -0700
    cartTrackVarCatalog: add a --reconcile that reads the tree refs #37838 --check only read the catalog itself, verifying that every family a type names exists, so a track-scoped cart variable added tomorrow was invisible to it. It never called the harvester at all. Adds --reconcile, which does: it compares what harvestCartVars finds against the catalog and reports a name in neither the catalog nor cartVarsNotCataloged.txt, silent and exit 0 otherwise, so it can run nightly. --update-baseline accepts new names as a reviewable diff. Matching is on the name with its leading separator stripped, because the harvester cannot always tell which separator a name is used with: the fourth argument of cart*ClosestToHome is a bare suffix while a safef("%s.%s") site carries the dot. A wildcard entry also registers its trailing component, since the harvester sees decorator.<name>.blockMode only as blockMode. Without that nine already-cataloged names read as new. Sixty-seven names are left in the baseline, and about fifteen of them look like real cart variables that were never cataloged, among them FilterLabel, FilterValuesDefault, HighlightType, minAc, fileSortOrder and the tablesTables paging vars. Cataloging those needs a read of the UI code and is not done here. harvestCartVars grows a harvest() entry point so the scan has one definition rather than one in main and a second written out by hand; --by-var output is unchanged.
  • lines changed 52, context: html, text, full: html, text
    99c145df11c04f80820690fd67e9499f296b4d7d Sat Aug 1 12:58:39 2026 -0700
    harvesters: resolve #defines per file, not pooled refs #37923 refs #37925 refs #37838 The first nightly run reported a new URL parameter, hggw_term, that had been in the tree since the hgGateway redesign. It was not new; the harvester had been answering the question differently in two checkouts of the same commit. SEARCH_TERM is "hggw_term" in hgGateway and "hgcd_term" in hgChooseDb. The #define table was pooled across the whole tree with setdefault, so the winner was whichever file the filesystem walk reached first, and hgGateway's reads came out as hgcd_term in my working tree and hggw_term in a fresh clone. For a nightly cron that means mail whenever a directory listing changes order, which is worse than no cron. So a name a file defines itself now wins, and a name the tree defines inconsistently resolves to {NAME} instead of to a guess. This is the call bdc473369e1 already made for char * constants, for the same reason and with the same tradeoff written up in the CONST_RE comment: an honest {ident} beats a confident wrong answer. Verified by harvesting both trees and diffing. Twelve names leave the URL baseline as a result, the gisaidTable and hgg_ prefix families, which were pooled values from sibling CGIs rather than reads in the file they were attributed to. Recovering those properly means following the #include chain to the header that defines them, which is not done here. The URL catalog carried hgt_tSearch twice, once correctly as the track search variable and once as hgGateway's search term, which was this bug showing up in the curated half. --check did not catch the duplicate because it only looks within a section. hgGateway now has hggw_term and hgChooseDb hgcd_term, both confirmed at their call sites and in their CGI's excludeVars.
• src/hg/utils/docent/README.md
  • lines changed 90, context: html, text, full: html, text
    fbbc2d15114548cc241e4b99dc83c0c9e79310ac Tue Jul 28 10:20:22 2026 -0700
    Docent: take track state from trackDb, add goShow, search the Convert target visibly refs #37892 Track visibility no longer comes from a table inside the renderer. docent.js used to carry per-composite cart parameters (mane/dbSnp155/clinvar), which pinned clinvarMain to dense for every clinvar step and quietly aliased dbSnp155 to a subtrack it does not name. It now reads the trackDb of the server it is driving (hubApi /list/tracks, cached a day in $TMPDIR) and derives what a step needs: the containers above a track, and the <name>_sel checkbox that actually decides a composite child. Nothing is pushed downward, since a container's visibility already reaches its selected children, so a script names only its deviations from trackDb. Scripts use real trackDb names; names trackDb does not have (hubs, custom tracks, a quickLift target) are sent as a literal name=mode. Two hgTracks mechanics this had to learn: a bare clinvarCnv=hide is dropped when the container's visibility is in the same request (the cart keeps clinvarCnv_sel=1 and the row still draws), so a step naming both a composite and a child of it is applied in two requests, container first. New goShow verb: types a position or a GENE NAME into the position bar and lets the page finish -- Search on hgTracks, the arrow on hgGateway. A gene name goes through the browser's own suggestion menu, so it lands on the gene rather than the search-results page. pick: disambiguates the menu. convert: now finds the target the way a user does, by typing it into the Convert page's own genome search bar and clicking the suggestion, and accepts shot: for the Convert page itself (opened / filled / result), which no other verb can reach. Stills of pages that are not hgTracks (an hgc detail page, an external page a link led to) are the viewport -- the top of the page -- instead of an element shot of the whole scrolling document, which ran to 4400px. A fading click ripple is removed before a still: it belongs to the video, not to a figure. Speed: FAST=1 (make FAST=1 BP1, DOCENT_FAST=1, or fast: true) drops everything that exists only for the video -- dwells, cursor animation, dropdown theatrics, screen recording, mp4 transcode -- taking BP1 from 64s to 24s for the same figures. docent.mk documents make -j for parallel scenarios; the trackDb cache is written via rename so concurrent runs cannot read a partial file, and holds the derived index (3MB) rather than hubApi's reply (30MB). DOCENT_TIME=1 prints where the wall clock went, DOCENT_ROWS=1 the rows hgTracks actually drew. Trimming the dwells exposed a real race in mouseover: dismissing the previous tooltip with a sleep and then waiting for "a tooltip is visible" was satisfied by the stale one, so a back-to-back pinned mouseover captured the previous item's text. It now waits for the old tooltip to be gone and for a new one whose content differs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 1, context: html, text, full: html, text
    bc027579f81bd61a816afc1e63ef6232d840e042 Wed Jul 29 12:16:12 2026 -0700
    Docent: publish the language reference as a generated page refs #37892 mkref.sh renders README.md to a standalone HTML page (default ~/public_html/docent.html), so the published reference is regenerated from the README rather than hand-maintained -- the previous hand-written page went stale as soon as the language was renamed. Also document the top-of-file `position:` key, which docent.js reads but the README did not list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 1, context: html, text, full: html, text
    ba3e92274483227d4969e7f9d89e6cd507e2bfb3 Fri Jul 31 14:46:55 2026 -0700
    Docent: drag takes a genomic range instead of from/to endpoints, refs #37892 The usual form is now one region and it zooms: drag: chr7:155,806,100-155,806,557 For any other action, or to pass shot:/track: as well, the region goes under range: in the map form: drag: {range: "chr7:155,806,100-155,806,557", shot: dragselect, then: highlight} A malformed range is reported at the drag step rather than failing later in the sweep. from:/to: still parse, so existing scripts keep working, and the fraction (fromFrac:/toFrac:) and pixel (fromX:/toX:) endpoints are untouched since neither has a genomic range to express. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 9, context: html, text, full: html, text
    790667d0f7ee6965244ed31318aa9459e82fda73 Mon Aug 3 16:50:48 2026 -0700
    Docent: add hideKids, and make a named mouseover wait for that item's own tooltip. hideKids is a container "visibility" meaning hide everything under it, so a child named alongside it is left the only one drawn. A superTrack needs it: unlike a composite, its own mode does not reach its children, so each comes up at its own trackDb visibility and {varsInPubs: show} draws all eight of its members however much an earlier "hide: all" hid. The expansion skips any child the step names itself and is sent in a round of its own AFTER the rest, since a subtrack hide travelling in the same request as its container can be dropped by the cart (#37953). It works on a composite or view too, where it deselects (_sel=0). The mouseover fix: tooltips are mouseenter-driven with a 500ms show delay and a 500ms hide grace (hg/js/utils.js addMouseover), so while the cursor glides in it crosses other items and one of THEIR tooltips is often still on screen when it arrives. Waiting for "some tooltip is visible" therefore recorded a neighbour's text -- an Alignment Differences mismatch pinned as the adjacent aligned block's "identical". That only bit pin:, because the dwell which follows let the right tooltip replace the wrong one before any shot: -- so a scenario's figures and its mp4 disagreed with each other, and FAST (a single cursor jump, never entering the neighbour) read correctly while the full run did not. A named mouseover now waits for the item's own text, taken from its map box and rendered the way the tooltip renders it (innerHTML then textContent: the attribute holds markup and undecoded entities such as &#9733;). Comparison is whitespace-insensitive on a distinctive prefix. A positional hover has no expected text, so it settles instead. DOCENT_ROWS=1 now also reports mouseovers -- which map boxes matched the name, where the cursor went, the tooltip expected from the box and the one that came up -- and warns when the item's own text never appears. Verified over all ten named-item mouseovers in the Current Protocols quickLift scenarios: no warnings, every tooltip correct. refs #37892 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
• src/hg/utils/docent/docent.js
  • lines changed 514, context: html, text, full: html, text
    fbbc2d15114548cc241e4b99dc83c0c9e79310ac Tue Jul 28 10:20:22 2026 -0700
    Docent: take track state from trackDb, add goShow, search the Convert target visibly refs #37892 Track visibility no longer comes from a table inside the renderer. docent.js used to carry per-composite cart parameters (mane/dbSnp155/clinvar), which pinned clinvarMain to dense for every clinvar step and quietly aliased dbSnp155 to a subtrack it does not name. It now reads the trackDb of the server it is driving (hubApi /list/tracks, cached a day in $TMPDIR) and derives what a step needs: the containers above a track, and the <name>_sel checkbox that actually decides a composite child. Nothing is pushed downward, since a container's visibility already reaches its selected children, so a script names only its deviations from trackDb. Scripts use real trackDb names; names trackDb does not have (hubs, custom tracks, a quickLift target) are sent as a literal name=mode. Two hgTracks mechanics this had to learn: a bare clinvarCnv=hide is dropped when the container's visibility is in the same request (the cart keeps clinvarCnv_sel=1 and the row still draws), so a step naming both a composite and a child of it is applied in two requests, container first. New goShow verb: types a position or a GENE NAME into the position bar and lets the page finish -- Search on hgTracks, the arrow on hgGateway. A gene name goes through the browser's own suggestion menu, so it lands on the gene rather than the search-results page. pick: disambiguates the menu. convert: now finds the target the way a user does, by typing it into the Convert page's own genome search bar and clicking the suggestion, and accepts shot: for the Convert page itself (opened / filled / result), which no other verb can reach. Stills of pages that are not hgTracks (an hgc detail page, an external page a link led to) are the viewport -- the top of the page -- instead of an element shot of the whole scrolling document, which ran to 4400px. A fading click ripple is removed before a still: it belongs to the video, not to a figure. Speed: FAST=1 (make FAST=1 BP1, DOCENT_FAST=1, or fast: true) drops everything that exists only for the video -- dwells, cursor animation, dropdown theatrics, screen recording, mp4 transcode -- taking BP1 from 64s to 24s for the same figures. docent.mk documents make -j for parallel scenarios; the trackDb cache is written via rename so concurrent runs cannot read a partial file, and holds the derived index (3MB) rather than hubApi's reply (30MB). DOCENT_TIME=1 prints where the wall clock went, DOCENT_ROWS=1 the rows hgTracks actually drew. Trimming the dwells exposed a real race in mouseover: dismissing the previous tooltip with a sleep and then waiting for "a tooltip is visible" was satisfied by the stale one, so a back-to-back pinned mouseover captured the previous item's text. It now waits for the old tooltip to be gone and for a new one whose content differs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 18, context: html, text, full: html, text
    ba3e92274483227d4969e7f9d89e6cd507e2bfb3 Fri Jul 31 14:46:55 2026 -0700
    Docent: drag takes a genomic range instead of from/to endpoints, refs #37892 The usual form is now one region and it zooms: drag: chr7:155,806,100-155,806,557 For any other action, or to pass shot:/track: as well, the region goes under range: in the map form: drag: {range: "chr7:155,806,100-155,806,557", shot: dragselect, then: highlight} A malformed range is reported at the drag step rather than failing later in the sweep. from:/to: still parse, so existing scripts keep working, and the fraction (fromFrac:/toFrac:) and pixel (fromX:/toX:) endpoints are untouched since neither has a genomic range to express. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 102, context: html, text, full: html, text
    790667d0f7ee6965244ed31318aa9459e82fda73 Mon Aug 3 16:50:48 2026 -0700
    Docent: add hideKids, and make a named mouseover wait for that item's own tooltip. hideKids is a container "visibility" meaning hide everything under it, so a child named alongside it is left the only one drawn. A superTrack needs it: unlike a composite, its own mode does not reach its children, so each comes up at its own trackDb visibility and {varsInPubs: show} draws all eight of its members however much an earlier "hide: all" hid. The expansion skips any child the step names itself and is sent in a round of its own AFTER the rest, since a subtrack hide travelling in the same request as its container can be dropped by the cart (#37953). It works on a composite or view too, where it deselects (_sel=0). The mouseover fix: tooltips are mouseenter-driven with a 500ms show delay and a 500ms hide grace (hg/js/utils.js addMouseover), so while the cursor glides in it crosses other items and one of THEIR tooltips is often still on screen when it arrives. Waiting for "some tooltip is visible" therefore recorded a neighbour's text -- an Alignment Differences mismatch pinned as the adjacent aligned block's "identical". That only bit pin:, because the dwell which follows let the right tooltip replace the wrong one before any shot: -- so a scenario's figures and its mp4 disagreed with each other, and FAST (a single cursor jump, never entering the neighbour) read correctly while the full run did not. A named mouseover now waits for the item's own text, taken from its map box and rendered the way the tooltip renders it (innerHTML then textContent: the attribute holds markup and undecoded entities such as &#9733;). Comparison is whitespace-insensitive on a distinctive prefix. A positional hover has no expected text, so it settles instead. DOCENT_ROWS=1 now also reports mouseovers -- which map boxes matched the name, where the cursor went, the tooltip expected from the box and the one that came up -- and warns when the item's own text never appears. Verified over all ten named-item mouseovers in the Current Protocols quickLift scenarios: no warnings, every tooltip correct. refs #37892 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
• src/hg/utils/docent/docent.mk
  • lines changed 8, context: html, text, full: html, text
    fbbc2d15114548cc241e4b99dc83c0c9e79310ac Tue Jul 28 10:20:22 2026 -0700
    Docent: take track state from trackDb, add goShow, search the Convert target visibly refs #37892 Track visibility no longer comes from a table inside the renderer. docent.js used to carry per-composite cart parameters (mane/dbSnp155/clinvar), which pinned clinvarMain to dense for every clinvar step and quietly aliased dbSnp155 to a subtrack it does not name. It now reads the trackDb of the server it is driving (hubApi /list/tracks, cached a day in $TMPDIR) and derives what a step needs: the containers above a track, and the <name>_sel checkbox that actually decides a composite child. Nothing is pushed downward, since a container's visibility already reaches its selected children, so a script names only its deviations from trackDb. Scripts use real trackDb names; names trackDb does not have (hubs, custom tracks, a quickLift target) are sent as a literal name=mode. Two hgTracks mechanics this had to learn: a bare clinvarCnv=hide is dropped when the container's visibility is in the same request (the cart keeps clinvarCnv_sel=1 and the row still draws), so a step naming both a composite and a child of it is applied in two requests, container first. New goShow verb: types a position or a GENE NAME into the position bar and lets the page finish -- Search on hgTracks, the arrow on hgGateway. A gene name goes through the browser's own suggestion menu, so it lands on the gene rather than the search-results page. pick: disambiguates the menu. convert: now finds the target the way a user does, by typing it into the Convert page's own genome search bar and clicking the suggestion, and accepts shot: for the Convert page itself (opened / filled / result), which no other verb can reach. Stills of pages that are not hgTracks (an hgc detail page, an external page a link led to) are the viewport -- the top of the page -- instead of an element shot of the whole scrolling document, which ran to 4400px. A fading click ripple is removed before a still: it belongs to the video, not to a figure. Speed: FAST=1 (make FAST=1 BP1, DOCENT_FAST=1, or fast: true) drops everything that exists only for the video -- dwells, cursor animation, dropdown theatrics, screen recording, mp4 transcode -- taking BP1 from 64s to 24s for the same figures. docent.mk documents make -j for parallel scenarios; the trackDb cache is written via rename so concurrent runs cannot read a partial file, and holds the derived index (3MB) rather than hubApi's reply (30MB). DOCENT_TIME=1 prints where the wall clock went, DOCENT_ROWS=1 the rows hgTracks actually drew. Trimming the dwells exposed a real race in mouseover: dismissing the previous tooltip with a sleep and then waiting for "a tooltip is visible" was satisfied by the stale one, so a back-to-back pinned mouseover captured the previous item's text. It now waits for the old tooltip to be gone and for a new one whose content differs. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
• src/hg/utils/docent/mkref.sh
  • lines changed 60, context: html, text, full: html, text
    bc027579f81bd61a816afc1e63ef6232d840e042 Wed Jul 29 12:16:12 2026 -0700
    Docent: publish the language reference as a generated page refs #37892 mkref.sh renders README.md to a standalone HTML page (default ~/public_html/docent.html), so the published reference is regenerated from the README rather than hand-maintained -- the previous hand-written page went stale as soon as the language was renamed. Also document the top-of-file `position:` key, which docent.js reads but the README did not list. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
• src/hg/utils/hgConfCatalog/harvestHgConf.py
  • lines changed 39, context: html, text, full: html, text
    bdc473369e1bb2a5666bd76626d449af50b81d40 Fri Jul 31 10:50:24 2026 -0700
    resolve char * constants per file in the harvesters, not pooled refs #37925 refs #37923 Both harvesters merged file-scope "char *NAME = \"literal\";" definitions into the same table as the #defines, keyed by identifier with setdefault, so one program's private constant answered for every other file in the tree and whichever file os.walk reached first won. harvestCartVars.py already did this per file; these two hoisted it and broke. What it was getting wrong: - hgConfCatalog listed encpipeline_prod as an hg.conf variable, verified, cited at hgTracks.c:9867. That line is cfgNamesWithPrefix(database), the <db>_TopLink family, and encpipeline_prod is a hardcoded MySQL database name in hg/encode/docId/docIdView/docIdView.c. The row is gone and the call site now reads {database}, a runtime value. - Twelve URL records named the wrong variable. Five cartRemove(cart, varName) sites were reported as removing dnaLines, which is what an assembly tool at primeMate.c:296 calls its own varName; three cartRemove(cart, var) sites read as num. They now read {varName} and {var}. - cfgValsWithPrefix passing its own prefix parameter through resolved to an unrelated utility's "char *prefix = \"\";", and an empty string is falsy, so the call site was dropped instead of reported. It goes through NAME_SKIP now like the other accessor plumbing. The deliberate cost is the genuine cross-file constant: snp125ColorSourceOldVar is defined in hg/cgilib/snp125Ui.c and declared extern in hg/inc/snp125Ui.h, so its hgTrackUi call site now reads {snp125ColorSourceOldVar} rather than snp125ColorSource. Pooling only extern-declared names would recover it and bring the collisions straight back, since database is extern in hgTracks and separately initialized to a literal in that ENCODE tool. hgConfCatalog --check still reports 0 problems and --reconcile is unchanged; urlCommandCatalog --check still reports catalog ok with the persistence audit at 41 known leaks, 0 unrecorded, 0 stale.
  • lines changed 4, context: html, text, full: html, text
    fece8651e5d986dc199aa4fa231b35863937ca4a Sat Aug 1 12:05:09 2026 -0700
    hgConfCatalog: make --reconcile fit for a nightly run refs #37925 --reconcile printed its whole report whether or not anything had changed, so as cron mail it would have been seventeen lines of standing drift every night with the one new setting buried in it. It now prints only what somebody has to act on, which is a setting the tree reads that the catalog has not classified, and a boolean flag filed neither gate nor knob. The drift moves behind --verbose. Silent and exit 0 means nothing new. Adds the missing row for blatNewPageBanner, which was the one real finding sitting in the report, and files it as a gate with the argument for calling it a knob recorded. A scan that finds almost nothing now fails instead of reporting all clear, since pointed at an empty tree every check below it comes up empty, and KENT_SRC lets a nightly aim at a pristine checkout rather than a working tree where a stray .c file would show up as a finding.
  • lines changed 47, context: html, text, full: html, text
    99c145df11c04f80820690fd67e9499f296b4d7d Sat Aug 1 12:58:39 2026 -0700
    harvesters: resolve #defines per file, not pooled refs #37923 refs #37925 refs #37838 The first nightly run reported a new URL parameter, hggw_term, that had been in the tree since the hgGateway redesign. It was not new; the harvester had been answering the question differently in two checkouts of the same commit. SEARCH_TERM is "hggw_term" in hgGateway and "hgcd_term" in hgChooseDb. The #define table was pooled across the whole tree with setdefault, so the winner was whichever file the filesystem walk reached first, and hgGateway's reads came out as hgcd_term in my working tree and hggw_term in a fresh clone. For a nightly cron that means mail whenever a directory listing changes order, which is worse than no cron. So a name a file defines itself now wins, and a name the tree defines inconsistently resolves to {NAME} instead of to a guess. This is the call bdc473369e1 already made for char * constants, for the same reason and with the same tradeoff written up in the CONST_RE comment: an honest {ident} beats a confident wrong answer. Verified by harvesting both trees and diffing. Twelve names leave the URL baseline as a result, the gisaidTable and hgg_ prefix families, which were pooled values from sibling CGIs rather than reads in the file they were attributed to. Recovering those properly means following the #include chain to the header that defines them, which is not done here. The URL catalog carried hgt_tSearch twice, once correctly as the track search variable and once as hgGateway's search term, which was this bug showing up in the curated half. --check did not catch the duplicate because it only looks within a section. hgGateway now has hggw_term and hgChooseDb hgcd_term, both confirmed at their call sites and in their CGI's excludeVars.
• src/hg/utils/hgConfCatalog/hgConfCatalog.py
  • lines changed 4, context: html, text, full: html, text
    4afc3a97cec36e9470e107bfe44398ee5ec65080 Fri Jul 31 10:33:43 2026 -0700
    hgConfCatalog: mark userDbName and sessionDbName as documented refs #37925 Both are now in product/ex.hg.conf, so they get public=True like the four sibling table-name settings around them. userDbName was documented under the wrong name until 225a9ac365d and sessionDbName was not documented at all, which is why neither carried the flag.
  • lines changed 3, context: html, text, full: html, text
    bdc473369e1bb2a5666bd76626d449af50b81d40 Fri Jul 31 10:50:24 2026 -0700
    resolve char * constants per file in the harvesters, not pooled refs #37925 refs #37923 Both harvesters merged file-scope "char *NAME = \"literal\";" definitions into the same table as the #defines, keyed by identifier with setdefault, so one program's private constant answered for every other file in the tree and whichever file os.walk reached first won. harvestCartVars.py already did this per file; these two hoisted it and broke. What it was getting wrong: - hgConfCatalog listed encpipeline_prod as an hg.conf variable, verified, cited at hgTracks.c:9867. That line is cfgNamesWithPrefix(database), the <db>_TopLink family, and encpipeline_prod is a hardcoded MySQL database name in hg/encode/docId/docIdView/docIdView.c. The row is gone and the call site now reads {database}, a runtime value. - Twelve URL records named the wrong variable. Five cartRemove(cart, varName) sites were reported as removing dnaLines, which is what an assembly tool at primeMate.c:296 calls its own varName; three cartRemove(cart, var) sites read as num. They now read {varName} and {var}. - cfgValsWithPrefix passing its own prefix parameter through resolved to an unrelated utility's "char *prefix = \"\";", and an empty string is falsy, so the call site was dropped instead of reported. It goes through NAME_SKIP now like the other accessor plumbing. The deliberate cost is the genuine cross-file constant: snp125ColorSourceOldVar is defined in hg/cgilib/snp125Ui.c and declared extern in hg/inc/snp125Ui.h, so its hgTrackUi call site now reads {snp125ColorSourceOldVar} rather than snp125ColorSource. Pooling only extern-declared names would recover it and bring the collisions straight back, since database is extern in hgTracks and separately initialized to a literal in that ENCODE tool. hgConfCatalog --check still reports 0 problems and --reconcile is unchanged; urlCommandCatalog --check still reports catalog ok with the persistence audit at 41 known leaks, 0 unrecorded, 0 stale.
  • lines changed 9, context: html, text, full: html, text
    fbfdc0a36bb6d3b0eb57dd07262c059086c7054e Fri Jul 31 14:55:15 2026 -0700
    hgConvert: link to the alignment request page, behind showLiftRequest, refs #37973 The Convert page's assembly list only offers targets that already have a chain from the source, so it is where a user finds out theirs is missing. Nothing in the tree linked to liftRequest.html, the page that requests a new alignment, so unless someone wrote to us and we sent the URL they were unlikely to find it. Adds "Target assembly not listed? Request an alignment" at the foot of the Destination section, gated by the new hg.conf flag showLiftRequest, which defaults FALSE. Registered in the hg.conf catalog as a release gate. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
  • lines changed 64, context: html, text, full: html, text
    fece8651e5d986dc199aa4fa231b35863937ca4a Sat Aug 1 12:05:09 2026 -0700
    hgConfCatalog: make --reconcile fit for a nightly run refs #37925 --reconcile printed its whole report whether or not anything had changed, so as cron mail it would have been seventeen lines of standing drift every night with the one new setting buried in it. It now prints only what somebody has to act on, which is a setting the tree reads that the catalog has not classified, and a boolean flag filed neither gate nor knob. The drift moves behind --verbose. Silent and exit 0 means nothing new. Adds the missing row for blatNewPageBanner, which was the one real finding sitting in the report, and files it as a gate with the argument for calling it a knob recorded. A scan that finds almost nothing now fails instead of reporting all clear, since pointed at an empty tree every check below it comes up empty, and KENT_SRC lets a nightly aim at a pristine checkout rather than a working tree where a stray .c file would show up as a finding.
  • lines changed 29, context: html, text, full: html, text
    488b403863dc439b5e9dfa0a8325bdfe886dd3a3 Tue Aug 4 06:51:42 2026 -0700
    hgConfCatalog: register login.emailLink, login.oauth.providers and the per-provider oauth family, refs #37925 The hgLogin email-link and social sign-in work added three hg.conf reads with no catalog rows, which is what --reconcile was failing on. login.emailLink is filed as a mirror knob with the gate argument recorded in debatable=; the per-provider settings are built with safef, so they are catalogued as a runtime name.
• src/hg/utils/urlCommandCatalog/harvestUrlCommands.py
  • lines changed 47, context: html, text, full: html, text
    bdc473369e1bb2a5666bd76626d449af50b81d40 Fri Jul 31 10:50:24 2026 -0700
    resolve char * constants per file in the harvesters, not pooled refs #37925 refs #37923 Both harvesters merged file-scope "char *NAME = \"literal\";" definitions into the same table as the #defines, keyed by identifier with setdefault, so one program's private constant answered for every other file in the tree and whichever file os.walk reached first won. harvestCartVars.py already did this per file; these two hoisted it and broke. What it was getting wrong: - hgConfCatalog listed encpipeline_prod as an hg.conf variable, verified, cited at hgTracks.c:9867. That line is cfgNamesWithPrefix(database), the <db>_TopLink family, and encpipeline_prod is a hardcoded MySQL database name in hg/encode/docId/docIdView/docIdView.c. The row is gone and the call site now reads {database}, a runtime value. - Twelve URL records named the wrong variable. Five cartRemove(cart, varName) sites were reported as removing dnaLines, which is what an assembly tool at primeMate.c:296 calls its own varName; three cartRemove(cart, var) sites read as num. They now read {varName} and {var}. - cfgValsWithPrefix passing its own prefix parameter through resolved to an unrelated utility's "char *prefix = \"\";", and an empty string is falsy, so the call site was dropped instead of reported. It goes through NAME_SKIP now like the other accessor plumbing. The deliberate cost is the genuine cross-file constant: snp125ColorSourceOldVar is defined in hg/cgilib/snp125Ui.c and declared extern in hg/inc/snp125Ui.h, so its hgTrackUi call site now reads {snp125ColorSourceOldVar} rather than snp125ColorSource. Pooling only extern-declared names would recover it and bring the collisions straight back, since database is extern in hgTracks and separately initialized to a literal in that ENCODE tool. hgConfCatalog --check still reports 0 problems and --reconcile is unchanged; urlCommandCatalog --check still reports catalog ok with the persistence audit at 41 known leaks, 0 unrecorded, 0 stale.
  • lines changed 4, context: html, text, full: html, text
    da5180baf458d64d523ec4e1cd96166bac1d3b25 Sat Aug 1 12:05:20 2026 -0700
    urlCommandCatalog: let --reconcile fail, so it can run nightly refs #37923 reconcile ended in a bare return 0, so it could not fail whatever it found, and it printed a six hundred line name diff every run. Most of that diff is structural rather than drift: the catalog covers what a user can put on a browser URL, while the harvester sees every cgiOptionalString in the tree, including form fields and the arguments of small utility CGIs. So the gap is now recorded in urlNamesNotCataloged.txt and reconcile reports only a name in neither the catalog nor that file, plus any disagreement between a persists=False claim and what the tree actually excludes or removes, in either direction. That second half was already computed and thrown away in a summary line. --update-baseline regenerates the file so accepting a name out of scope is a reviewable diff rather than a hand edit. The baseline's first version was accepted wholesale and says so, except for blatNewPage and blatReopen, which the new BLAT results page puts on a URL and which are now cataloged properly. A scan that finds almost nothing fails rather than reporting all clear, and KENT_SRC lets a nightly aim at a pristine checkout.
  • lines changed 51, context: html, text, full: html, text
    99c145df11c04f80820690fd67e9499f296b4d7d Sat Aug 1 12:58:39 2026 -0700
    harvesters: resolve #defines per file, not pooled refs #37923 refs #37925 refs #37838 The first nightly run reported a new URL parameter, hggw_term, that had been in the tree since the hgGateway redesign. It was not new; the harvester had been answering the question differently in two checkouts of the same commit. SEARCH_TERM is "hggw_term" in hgGateway and "hgcd_term" in hgChooseDb. The #define table was pooled across the whole tree with setdefault, so the winner was whichever file the filesystem walk reached first, and hgGateway's reads came out as hgcd_term in my working tree and hggw_term in a fresh clone. For a nightly cron that means mail whenever a directory listing changes order, which is worse than no cron. So a name a file defines itself now wins, and a name the tree defines inconsistently resolves to {NAME} instead of to a guess. This is the call bdc473369e1 already made for char * constants, for the same reason and with the same tradeoff written up in the CONST_RE comment: an honest {ident} beats a confident wrong answer. Verified by harvesting both trees and diffing. Twelve names leave the URL baseline as a result, the gisaidTable and hgg_ prefix families, which were pooled values from sibling CGIs rather than reads in the file they were attributed to. Recovering those properly means following the #include chain to the header that defines them, which is not done here. The URL catalog carried hgt_tSearch twice, once correctly as the track search variable and once as hgGateway's search term, which was this bug showing up in the curated half. --check did not catch the duplicate because it only looks within a section. hgGateway now has hggw_term and hgChooseDb hgcd_term, both confirmed at their call sites and in their CGI's excludeVars.
• src/hg/utils/urlCommandCatalog/urlCommandCatalog.py
  • lines changed 217, context: html, text, full: html, text
    da5180baf458d64d523ec4e1cd96166bac1d3b25 Sat Aug 1 12:05:20 2026 -0700
    urlCommandCatalog: let --reconcile fail, so it can run nightly refs #37923 reconcile ended in a bare return 0, so it could not fail whatever it found, and it printed a six hundred line name diff every run. Most of that diff is structural rather than drift: the catalog covers what a user can put on a browser URL, while the harvester sees every cgiOptionalString in the tree, including form fields and the arguments of small utility CGIs. So the gap is now recorded in urlNamesNotCataloged.txt and reconcile reports only a name in neither the catalog nor that file, plus any disagreement between a persists=False claim and what the tree actually excludes or removes, in either direction. That second half was already computed and thrown away in a summary line. --update-baseline regenerates the file so accepting a name out of scope is a reviewable diff rather than a hand edit. The baseline's first version was accepted wholesale and says so, except for blatNewPage and blatReopen, which the new BLAT results page puts on a URL and which are now cataloged properly. A scan that finds almost nothing fails rather than reporting all clear, and KENT_SRC lets a nightly aim at a pristine checkout.
  • lines changed 11, context: html, text, full: html, text
    99c145df11c04f80820690fd67e9499f296b4d7d Sat Aug 1 12:58:39 2026 -0700
    harvesters: resolve #defines per file, not pooled refs #37923 refs #37925 refs #37838 The first nightly run reported a new URL parameter, hggw_term, that had been in the tree since the hgGateway redesign. It was not new; the harvester had been answering the question differently in two checkouts of the same commit. SEARCH_TERM is "hggw_term" in hgGateway and "hgcd_term" in hgChooseDb. The #define table was pooled across the whole tree with setdefault, so the winner was whichever file the filesystem walk reached first, and hgGateway's reads came out as hgcd_term in my working tree and hggw_term in a fresh clone. For a nightly cron that means mail whenever a directory listing changes order, which is worse than no cron. So a name a file defines itself now wins, and a name the tree defines inconsistently resolves to {NAME} instead of to a guess. This is the call bdc473369e1 already made for char * constants, for the same reason and with the same tradeoff written up in the CONST_RE comment: an honest {ident} beats a confident wrong answer. Verified by harvesting both trees and diffing. Twelve names leave the URL baseline as a result, the gisaidTable and hgg_ prefix families, which were pooled values from sibling CGIs rather than reads in the file they were attributed to. Recovering those properly means following the #include chain to the header that defines them, which is not done here. The URL catalog carried hgt_tSearch twice, once correctly as the track search variable and once as hgGateway's search term, which was this bug showing up in the curated half. --check did not catch the duplicate because it only looks within a section. hgGateway now has hggw_term and hgChooseDb hgcd_term, both confirmed at their call sites and in their CGI's excludeVars.
• src/hg/utils/urlCommandCatalog/urlNamesNotCataloged.txt
  • lines changed 525, context: html, text, full: html, text
    da5180baf458d64d523ec4e1cd96166bac1d3b25 Sat Aug 1 12:05:20 2026 -0700
    urlCommandCatalog: let --reconcile fail, so it can run nightly refs #37923 reconcile ended in a bare return 0, so it could not fail whatever it found, and it printed a six hundred line name diff every run. Most of that diff is structural rather than drift: the catalog covers what a user can put on a browser URL, while the harvester sees every cgiOptionalString in the tree, including form fields and the arguments of small utility CGIs. So the gap is now recorded in urlNamesNotCataloged.txt and reconcile reports only a name in neither the catalog nor that file, plus any disagreement between a persists=False claim and what the tree actually excludes or removes, in either direction. That second half was already computed and thrown away in a summary line. --update-baseline regenerates the file so accepting a name out of scope is a reviewable diff rather than a hand edit. The baseline's first version was accepted wholesale and says so, except for blatNewPage and blatReopen, which the new BLAT results page puts on a URL and which are now cataloged properly. A scan that finds almost nothing fails rather than reporting all clear, and KENT_SRC lets a nightly aim at a pristine checkout.
  • lines changed 12, context: html, text, full: html, text
    99c145df11c04f80820690fd67e9499f296b4d7d Sat Aug 1 12:58:39 2026 -0700
    harvesters: resolve #defines per file, not pooled refs #37923 refs #37925 refs #37838 The first nightly run reported a new URL parameter, hggw_term, that had been in the tree since the hgGateway redesign. It was not new; the harvester had been answering the question differently in two checkouts of the same commit. SEARCH_TERM is "hggw_term" in hgGateway and "hgcd_term" in hgChooseDb. The #define table was pooled across the whole tree with setdefault, so the winner was whichever file the filesystem walk reached first, and hgGateway's reads came out as hgcd_term in my working tree and hggw_term in a fresh clone. For a nightly cron that means mail whenever a directory listing changes order, which is worse than no cron. So a name a file defines itself now wins, and a name the tree defines inconsistently resolves to {NAME} instead of to a guess. This is the call bdc473369e1 already made for char * constants, for the same reason and with the same tradeoff written up in the CONST_RE comment: an honest {ident} beats a confident wrong answer. Verified by harvesting both trees and diffing. Twelve names leave the URL baseline as a result, the gisaidTable and hgg_ prefix families, which were pooled values from sibling CGIs rather than reads in the file they were attributed to. Recovering those properly means following the #include chain to the header that defines them, which is not done here. The URL catalog carried hgt_tSearch twice, once correctly as the track search variable and once as hgGateway's search term, which was this bug showing up in the curated half. --check did not catch the duplicate because it only looks within a section. hgGateway now has hggw_term and hgChooseDb hgcd_term, both confirmed at their call sites and in their CGI's excludeVars.
• src/product/ex.hg.conf
  • lines changed 4, context: html, text, full: html, text
    225a9ac365d237639420aed284a51c3c9607a4bb Fri Jul 31 10:32:44 2026 -0700
    ex.hg.conf documents userDbTableName but the code reads userDbName refs #37925 A mirror that copied the example got no error, just silently kept using the default userDb table, since nothing in the tree reads userDbTableName. hg/inc/cartDb.h:80 defines the setting as userDbName, read at hg/lib/cartDb.c:325 through cfgOptionEnvDefault. Also documents sessionDbName, the matching setting for the session cart table, which the example did not mention at all. Found while building the hg.conf registry.