Hi, Carrie

Can you (or the other user) open the javascript console and try to load the history again in order to reproduce the problem?

You can open the console: - by going to the menu command: Tools->Web Developer->Web Console in Firefox. - going to: the 'control menu' (the three horizontal bar button on the top right)->Tools->Javascript Console in Chrome. - by enabling the developer tools and going to Develop->Show Error Console in Safari. Enable the developer menu by going to preferences->advanced->Show develop menu in menu bar.

It may be there's an error on the client side involved and having this open will show that error. Additionally, if an API call is returning a 400 range http error - you won't see it in the server logs.

Thanks for the help and let me know what you find, Carl

On Wed, Mar 12, 2014 at 10:22 AM, Ganote, Carrie L cganote@iu.edu wrote:

Hi Hans,

Thanks for the advice! Sadly, I think our situations might not be the same. We've been using external auth for a long time, so it's definitely not a new change, and the user in question created their account after this was in place. We log our users in with just their IU username, and tack the "@indiana.edu" onto it with Apache to create the email address after authenticating the username through IU. I checked the galaxy_user table, and there doesn't seem to be any accidental duplicates or funny business with the user name.

User is active, external, not deleted, not purged, and we don't enforce any disk quotas.

I pulled the histories associated with the user id: select * from history where user_id = '95' ; id | create_time | update_time | user_id | name | hid_counter | deleted | purged | genome_build | importable | slug | published | importing

------+----------------------------+----------------------------+---------+--------------------+-------------+---------+--------+--------------+------------+------+-----------+----------- 1665 | 2014-02-23 18:42:23.497483 | 2014-03-11 19:04:55.614609 | 95 | Unnamed history | 5 | t | f | dm3 | f | | f | f 1722 | 2014-02-28 20:46:50.292015 | 2014-03-11 19:06:47.498152 | 95 | RNAseq | 7 | f | f | ? | f | | f | f 1811 | 2014-03-11 19:04:55.910381 | 2014-03-11 19:13:06.82213 | 95 | Unnamed history | 2 | f | f | ? | f | | f | f (3 rows)

I took a look at "RNAseq": select * from history_dataset_association where history_id = '1722'; id: 10027 history_id: 1722 dataset_id: 7258 create_time: 2014-02-28 20:51:32.369667 update_time: 2014-03-06 15:37:27.033951 copied_from_history_dataset_association_id: 9778 hid: 4 name : https://usegalaxy.org/datasets/bbd44e69cb8906b52e29eb7a7c6c4900/display?to_e... peek:@HWI-B5-690_0086_FC:2:1:2711:936#CNNNNN/1 ... (this checks out with the datafile) extension: txt metadata: {"data_lines": 145087556, "dbkey": "dm3"} deleted: f visible: t purged: f extended_metadata_id: uploaded txt file

I found this file in the dataset_files and there doesn't appear to be anything wrong about it. It appears that the datasets in question were downloaded from Galaxy main (by the looks of the upload URL).

I'm at a loss. I'll ask the user to clear all their browser information just in case this is something simple like that. I'll ask them to re-upload those files. In the meantime, any other sleuthing suggestions would be greatly appreciated.

Sincerely,

Carrie Ganote

---

From: Hans-Rudolf Hotz [hrh@fmi.ch] Sent: Wednesday, March 12, 2014 5:07 AM To: Ganote, Carrie L Cc: galaxy-dev@lists.bx.psu.edu Subject: Re: [galaxy-dev] History seems to load forever

Hi Carrie

Was the history which is causing troubles created before you switched to external authentication? Or has the user a slightly different e-mail address now? eg different use of capital letters, like 'foo.bar@home' and 'Foo.Bar@home' - we had such problems, when we switched to external authentication.

I had to dig into our MySQL database and fix the "galaxy_user" table. In your case, I recommend looking at the "galaxy_user" table and check whether the user has more than one entry. Take the "id" (ie the number) and search the "history" table using the id as 'user_id'. I would guess you can fix your problem by changing the 'user_id' in the "history" table for the history which is causing troubles.

BUT, BE VERY CAREFUL! you can do a lot of damage to the database. Switch off the galaxy server first, and MAKE a back up the database before you change anything.

Regards, Hans-Rudolf

On 03/11/2014 11:58 PM, Ganote, Carrie L wrote:

...

Hi List,

I just pulled and merged from galaxy-dist (I think it's dc067a95261d), updated my database, and migrated my tools. The issues I am able to see are minor, but I have a user who can no longer access a particular history. It apparently just hangs. If they delete the history, Galaxy responds, but it will hang again when they try to add back any datasets. Unfortunately, I don't see any errors in the paster logs about this. I fear that their dataset entries in the Postgresql db have been corrupted during the update, or perhaps the files themselves were purged. I cannot reproduce their issues with my own histories - I'm able to bring up saved histories and upload etc. I don't know if they can share a history if it can't be loaded. How should I troubleshoot this? I'm set up to authenticate through apache, which makes it harder to get in as the user and see what's up. Is there an easy way to find out what histories belong to what users? I can search the database?

Any advice would be greatly appreciated!

-Carrie

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/

---

Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/

To search Galaxy mailing lists use the unified search at: http://galaxyproject.org/search/mailinglists/