Något fel i inladdningen av t.ex cust004 -> 218

[robinandeer]

När Scout försöker hämta compounds:

Traceback (most recent call last):
  File "/home/scout/scoutApp/lib/python2.7/site-packages/tornado/web.py", line 1220, in _when_complete
    callback()
  File "/home/scout/scoutApp/lib/python2.7/site-packages/tornado/web.py", line 1241, in _execute_method
    self._when_complete(method(*self.path_args, **self.path_kwargs),
  File "/home/scout/scoutApp/clinicalDB_dev/clinic.py", line 184, in get
    if tData[0].iem == 'NO':
IndexError: list index out of range

När man trycker på IGV:

Traceback (most recent call last):
  File "/home/scout/scoutApp/lib/python2.7/site-packages/tornado/web.py", line 1220, in _when_complete
    callback()
  File "/home/scout/scoutApp/lib/python2.7/site-packages/tornado/web.py", line 1241, in _execute_method
    self._when_complete(method(*self.path_args, **self.path_kwargs),
  File "/home/scout/scoutApp/clinicalDB_dev/clinic.py", line 564, in get
    where pk='%s'""" % (variant))
  File "/home/scout/scoutApp/lib/python2.7/site-packages/torndb.py", line 132, in query
    self._execute(cursor, query, parameters, kwparameters)
  File "/home/scout/scoutApp/lib/python2.7/site-packages/torndb.py", line 226, in _execute
    return cursor.execute(query, kwparameters or parameters)
  File "/home/scout/scoutApp/lib/python2.7/site-packages/MySQLdb/cursors.py", line 205, in execute
    self.errorhandler(self, exc, value)
  File "/home/scout/scoutApp/lib/python2.7/site-packages/MySQLdb/connections.py", line 36, in defaulterrorhandler
    raise errorclass, errorvalue
OperationalError: (1052, "Column 'pk' in where clause is ambiguous")

[MatsDahlberg]

Jag kan inte reproducera detta.

Kan du ange med vilken URL du anropar?

(Ange alltid URL när du får problem, annars är det ofta svårt att reproducera.)

[robinandeer]

Sorry :pensive:

Compounds callet: https://clinical-db.scilifelab.se:8081/api/v1/compounds?variant_id=76054947

IGV: https://clinical-db.scilifelab.se:8081/api/v1/variants/76054958/igv.xml Men jag kan inte heller upprepa felet även om det tar lång tid för .jnlp-filen att laddas ner.

[MatsDahlberg]

Ok, det är ngt skumt. Så här ser compound-callet ut för mig:

Jag ska försöka lista ut vad det beror på att vi får olika svar.

[MatsDahlberg]

Jag har hittat problemet, jag missade att ta bort rader ur en tabell när man laddade om en familj flera gånger. Så det fanns kvar referenser till variant_idn som inte fanns kvar i moder-tabellen.

Jag kör ett skript som städar detta i databasen just nu. Borde vara klart om ett par timmar.

[MatsDahlberg]

Nu får man inga fel när man gör compund-call. Men det finns ett annat problem. Av ngn anledning så får man inte tillbaka några compounds för cust004-körningar.

Jag ska försöka fixa det imorgon.

[MatsDahlberg]

Nu funkar compunds för cust004. Problemet var att jag använde den cookie som du skickar med (den verkar alltid vara satt till institute='CMMS').

[MatsDahlberg]

Angående IGV så får jag inga anrop på clinical-db:8084/static/

Kan du testa IGV och se om du ser vart dom tar vägen?

[robinandeer]

Ojdå, jag ska kolla vad jag gör med cookien. Ska jag skicka med institute som en i en query string till compounds?

Återkommer om IGV.

[MatsDahlberg]

För tydligheten så vore det bra om du adderar institute i query string. Nu fuskar jag fram institute via lite frågo i databasen.

[robinandeer]

Första callet till IGV gör jag på /variants/76754136/igv.xml (av någon anledning tar det lång tid)

Testa nu även att öppna IGV. Ser du om det gjordes några call på t.ex: /static/mnt/hds/proj/cust004/analysis/exomes/218/mosaik/GATK/218_lanes_1122_sorted_merged_pmd_rreal_brecal.bai?

[MatsDahlberg]

Jag märkte oxå att det tar väldigt lång tid att generera jnlp-filen. Jag undersöker varför det är så.

När jag startar IGV så får jag följande felmeddelande:

Men i logfilen dyker det sedan aldrig upp några anrop till /static/mnt/hds/proj/... så jag undrar om flask-servern verkligen skickar dessa calls-vidare?

[robinandeer]

OK, då vet jag vad jag ska testa att ändra i Flask. Det är en del URLer som överlappar varandra så jag misstänker att de måste definieras i rätt ordning.

[robinandeer]

Kan vara jag som ändrat mitt API utan att meddela dig. Nu förväntar sig nämligen Flask att /static anropas från /api/v1/remote/static/ som för resten av API-callen.

Du skriver väl jnlp-filen? Om du ändrar https://clinical-db.scilifelab.se:8081/remote/static/<path> till https://clinical-db.scilifelab.se:8081/api/v1/remote/static/<path> så borde det funka igen. Sorry :)

[MatsDahlberg]

Ok, jag har fixat problemet med att det tar lång tid att generera jnlp-filen.

Jag har ändrat till /api/v1 nu det tar ett par minuter sedan dyker följande felmeddelande upp i IGV:

Error loading https://clinical-db.scilifelab.se:8081/api/v1/remote/static/mnt/hds/proj/cust003/analysis/exomes/163-1-1A/mosaik/GATK/163-1-1A_lanes_1122_sorted_merged_pmd_rreal_brecal.bam: Read error; BinaryCodec in readmode; streamed file (filename not available)

Jag får fortfarande inte ngt anrop till /static/mnt/hds/...

[robinandeer]

Okej, nu verkar det som Flask-inloggningen inte är kompatibel med IGV. Flask redirect-ar alla calls från IGV (kanske för att det inte finns någon cookie med inloggningsuppgifter).

Jag testade att ta bort inloggningskravet från /remote/static/ och då funkar det iaf lokalt.

Jag antar att det bara är att ta bort den begränsningen om det ska funka?

[MatsDahlberg]

Hmm, betyder det att folk ute på stan kommer kunna ladda ner bam-filer utan att vara inloggade?

[MatsDahlberg]

Jag får samma fel som förut. Jag klickar på IGV-länken när jag är på sidan: https://clinical-db.scilifelab.se:8083/#/variants/CMMS/163/EP/76646558?database=EP

[robinandeer]

Precis... blir lite "security by obscurity" eftersom man måste känna till länken antar jag.

Möjligen att man i servern skulle kunna kolla att en sådan request kommer just ifrån IGV och inte från vilken browser etc. som helst?

Nu har jag uppdaterat development-porten med en ny version av Scout där jag inte längre kollar inloggning för remote/static. Kolla gärna om det funkar.

Även requests till /compounds ska nu innehålla "institute" som ett argument.

BTW Går det på något sätt att sätta domänen (och porten) dynamisk i jnlp-filen? Just nu antas det att man kommer ifrån "clinical-db.scilifelab.se:8081". Jag kan skicka med ett nytt argument om det hjälper.

[MatsDahlberg]

Om du vill kan du skicka med domänen och porten som ett argument i anropet till: /variants/(?P[\d]+)/igv.xml

[robinandeer]

Det vore bra. Vad brukar man kalla den; "host" eller "url"?

Det är också därför som det som du fick samma fel när du testade med https://clinical-db.scilifelab.se:8083/#/variants/CMMS/163/EP/76646558?database=EP. Den requesten gick till port 8081.

För mig funkar det fint nu på :8083 (om jag manuellt ändrar porten i jnlp-filen).

[MatsDahlberg]

För mig går det lika bra med 'host' eller 'url'. Jag har ingen uppfattning i frågan.

[robinandeer]

OK. "origin" från JavaScript verkar vara det jag letade efter: location.origin=https://clinical-db.scilifelab.se:8083.

Requesten blir alltså: /variants/{{ variant_id }}//igv.xml?origin={{ origin }}

[MatsDahlberg]

Låter bra.

[MatsDahlberg]

Nu funkar det men i requesten som du skickar står det host och inte origin.

[robinandeer]

Tack, där var jag lite för snabb... nu ska det vara fixat.

[MatsDahlberg]

Kanon, nu har jag ändrat till origin oxå. Stänger detta tillsvidare.