443d7aad57553f2606be41a934cb4dab46019e09
braney
  Fri Sep 4 12:10:00 2026 -0700
docent: first eleven regression tests, one per fixed bug, refs #38252

Ten assert the behavior their ticket says is correct; the eleventh is an xfail.
All eleven pass against genome-test, 40s for the set.

rm35333  bigBed schema vs trackDb type mismatch, no SEGFAULT
rm35920  wrong bigBed type in a hub, no crash and no garbage item label
rm36029  a MAF displays after several phyloP tracks are on
rm36331  quickLift of the GENCODE Archive container, no "Unknown database"
rm36514  a chromosome search after a quickLift hop
rm36702  quickLift hg19 to hs1, no "Unknown database"
rm36798  the two OMIM tracks survive a configure submit
rm37388  hgc on a quickLifted hub item, no connect to the source assembly
rm37520  lifted tracks survive a hop to another genome and back
rm37906  Neandertal tracks draw data in a narrow window on hg18

rm36540 is the xfail, and it is worth reading. The ticket is Closed, but the
symptom is present on genome.ucsc.edu (v502), hgwbeta (v503) and genome-test
(v503), measured with the reporter's own hub URL as well as with our copy of it:
genome= instead of db= for a hub-backed assembly still reaches a query against a
chromInfo table that does not exist. There is no fixed behavior to assert, so it
is pinned as an xfail and the run fails if it ever starts passing.

Six of these build their own state rather than loading the session their ticket
names, which is deliberate: a session on someone's account can be renamed or
deleted, and hgTracks answers a missing session with a 200 and an early-error
page that every noText: assertion passes on. Where a session is genuinely the
cheapest way to a state (rm37388), the script also asserts noText: "Could not
find session" so that a deleted session fails loudly instead of quietly.

Four traps cost a run each and are written into the scripts that hit them, since
the next twenty-nine will hit them too: a container never gets an img_data_ row
(the rows carry its children's names); a leaf track with no features at the
ticket's position has no row either, so a lifted view is better checked by its
own quickLiftChain; `track:` sends a plain name and cannot turn on a track in an
ATTACHED hub, whose cart variable carries the hub prefix; and asking for one view
of a composite turns its sibling views on as well.

diff --git src/hg/utils/docent/tests/regress/rm37906.docent.yaml src/hg/utils/docent/tests/regress/rm37906.docent.yaml
new file mode 100644
index 00000000000..3d6691d0331
--- /dev/null
+++ src/hg/utils/docent/tests/regress/rm37906.docent.yaml
@@ -0,0 +1,37 @@
+# #37906 -- Neandertal Cntgs and Neandertal Seq drew nothing when the window was narrow.
+#
+# Reported on hg18 at chr19:56,940,838-56,946,943 (the FPR1 gene): no data under either
+# track, and two clicks of Zoom out 3x brought some of it back. So the assertion is that
+# data really is drawn at the narrow window the reporter used.
+#
+# The ticket links a session, and this deliberately does not use it. The link is
+# /s/gperez2/mlq_37881 on the RR, and RR sessions live in hgcentral, so it cannot be
+# loaded from genome-test at all. There is a Gerardo/mlq_37881 on genome-test, but it is a
+# different session. Reaching for it because the name matched would have made this test
+# pass or fail for reasons unconnected to the bug.
+#
+# Two things about the names, both of which cost a run to find out:
+#
+#   * "Neandertal Cntgs" (ntSeqContigs) and "Neandertal Seq" (ntSeqReads) are COMPOSITES,
+#     not tracks. A container never gets an img_data_ row of its own, so asserting on
+#     those two names can only ever fail. The rows carry the children's names.
+#   * ntSeqContigs has one child, bamAll. ntSeqReads has six bamSL* children, and at this
+#     window only some of them have reads: on 2026-09-04 bamSLMez1, bamSLVi33dot16,
+#     bamSLVi33dot25 and bamSLVi33dot26 drew, while bamSLDenisova did not. Naming all six
+#     would make the test fail whenever a sample legitimately has nothing here, so it
+#     names one child per composite instead: bamAll for the Cntgs side, bamSLMez1 for the
+#     Seq side. Those two are what "no data under either track" was about.
+target: genome-test
+db: hg18
+position: chr19:56940838-56946943
+reset: true
+fast: true
+steps:
+  - go: chr19:56940838-56946943
+  - hide: all
+  - track: {ntSeqContigs: pack, ntSeqReads: pack}
+
+  # A track that is on but has nothing in view still gets a row, so this is a check that
+  # the data was found rather than that the track was enabled. That is the distinction the
+  # bug turned on: the tracks were on the whole time and drew nothing.
+  - expect: {rows: [bamAll, bamSLMez1], noText: "Warning/Error"}