Conditional parameters regression: KeyError: '__current_case__'
Hi Dan, I just started work on updating my MIRA wrapper, and fell over a regression present of 6079:5e6254f2b9e3, steps to reproduce on Linux:- 1. Install latest Galaxy 2. Install my MIRA wrapper v0.0.1 from the tool shed (don't need MIRA for this) 3. Run Galaxy 4. Select the MIRA tool 5. Change "Backbones/reference chromosomes?" or "Sanger/Capillary reads?" or "454 reads?" or "Solexa/Illumina reads?" to yes 6. Instead of new file parameter appearing, get a KeyError: '__current_case__' exception (details below). Shorter example without a 3rd party tool: 1. Install latest Galaxy 2. Run Galaxy 3. Select the "Convert SOLiD output to fastq" tool 4. Change "Is this a mate-pair run?" to yes 5. Instead of new file parameters appearing, get a KeyError: '__current_case__' exception. By going through recent commits and retesting, I found the commit which caused this regression: changeset: 6078:894112e0b9d5 user: Daniel Blankenberg <dan@bx.psu.edu> date: Thu Jun 09 11:26:41 2011 -0400 summary: Some fixes for interplay between DataToolParameter, implicit datatype conversion and dynamic select lists. Closes #491. I guess there are downsides to running my development environment off galaxy-central rather than galaxy-dist ... Peter ----- Exception details, KeyError: '__current_case__' clear this clear this URL: http://127.0.0.1:8081/tool_runner/index Module weberror.evalexception.middleware:364 in respond view << try: __traceback_supplement__ = errormiddleware.Supplement, self, environ app_iter = self.application(environ, detect_start_response) try: return_iter = list(app_iter)>> app_iter = self.application(environ, detect_start_response) Module paste.debug.prints:98 in __call__ view << try: status, headers, body = wsgilib.intercept_output( environ, self.app) if status is None: # Some error occurred>> environ, self.app) Module paste.wsgilib:539 in intercept_output view << data.append(headers) return output.write app_iter = application(environ, replacement_start_response) if data[0] is None: return (None, None, app_iter)>> app_iter = application(environ, replacement_start_response) Module paste.recursive:80 in __call__ view << environ['paste.recursive.script_name'] = my_script_name try: return self.application(environ, start_response) except ForwardRequestException, e: middleware = CheckForRecursionMiddleware(>> return self.application(environ, start_response) Module paste.httpexceptions:632 in __call__ view << []).append(HTTPException) try: return self.application(environ, start_response) except HTTPException, exc: return exc(environ, start_response)>> return self.application(environ, start_response) Module galaxy.web.framework.base:145 in __call__ view << kwargs.pop( '_', None ) try: body = method( trans, **kwargs ) except Exception, e: body = self.handle_controller_exception( e, trans, **kwargs )>> body = method( trans, **kwargs ) Module galaxy.web.controllers.tool_runner:68 in index view << # so make sure to create a new history if we've never had one before. history = trans.get_history( create=True ) template, vars = tool.handle_input( trans, params.__dict__ ) if len(params) > 0: trans.log_event( "Tool params: %s" % (str(params)), tool_id=tool_id )>> template, vars = tool.handle_input( trans, params.__dict__ ) Module galaxy.tools:966 in handle_input view << # Update state for all inputs on the current page taking new # values from `incoming`. errors = self.update_state( trans, self.inputs_by_page[state.page], state.inputs, incoming ) # If the tool provides a `validate_input` hook, call it. validate_input = self.get_hook( 'validate_input' )>> errors = self.update_state( trans, self.inputs_by_page[state.page], state.inputs, incoming ) Module galaxy.tools:1159 in update_state view << group_state = state[input.name] = {} # TODO: we should try to preserve values if we can self.fill_in_new_state( trans, input.cases[current_case].inputs, group_state, context ) group_errors = dict() group_old_errors = dict()>> self.fill_in_new_state( trans, input.cases[current_case].inputs, group_state, context ) Module galaxy.tools:876 in fill_in_new_state view << context = ExpressionContext( state, context ) for input in inputs.itervalues(): state[ input.name ] = input.get_initial_value( trans, context ) def get_param_html_map( self, trans, page=0, other_values={} ):>> state[ input.name ] = input.get_initial_value( trans, context ) Module galaxy.tools.parameters.basic:1384 in get_initial_value view << # Also collect children via association object dataset_collector( data.children ) dataset_collector( history.datasets ) most_recent_dataset = most_recent_dataset.pop() if most_recent_dataset is not None:>> dataset_collector( history.datasets ) Module galaxy.tools.parameters.basic:1378 in dataset_collector view << return False for i, data in enumerate( datasets ): if data.visible and not data.deleted and data.state not in [data.states.ERROR, data.states.DISCARDED] and ( isinstance( data.datatype, self.formats) or is_convertable( data ) ): if self.options and self._options_filter_attribute( data ) != filter_value: continue>> if data.visible and not data.deleted and data.state not in [data.states.ERROR, data.states.DISCARDED] and ( isinstance( data.datatype, self.formats) or is_convertable( data ) ): Module galaxy.tools.parameters.basic:1373 in is_convertable view << def dataset_collector( datasets ): def is_convertable( dataset ): target_ext, converted_dataset = dataset.find_conversion_destination( self.formats, converter_safe = self.converter_safe( context, trans ) ) if target_ext is not None: return True>> target_ext, converted_dataset = dataset.find_conversion_destination( self.formats, converter_safe = self.converter_safe( context, trans ) ) Module galaxy.tools.parameters.basic:1458 in converter_safe view << if input.is_dynamic and ( input.dynamic_options or ( not input.dynamic_options and not input.options ) or not input.options.converter_safe ): converter_safe[0] = False #This option does not allow for conversion, i.e. uses contents of dataset file to generate options self.tool.visit_inputs( other_values, visitor ) return False not in converter_safe >> self.tool.visit_inputs( other_values, visitor ) Module galaxy.tools:931 in visit_inputs view << callback( "", input, value[input.name] ) else: input.visit_inputs( "", value[input.name], callback ) def handle_input( self, trans, incoming, history=None ):>> input.visit_inputs( "", value[input.name], callback ) Module galaxy.tools.parameters.grouping:455 in visit_inputs view << return rval def visit_inputs( self, prefix, value, callback ): current_case = value['__current_case__'] new_prefix = prefix + "%s|" % ( self.name ) for input in self.cases[current_case].inputs.itervalues():>> current_case = value['__current_case__'] KeyError: '__current_case__'
On Wed, Jun 15, 2011 at 4:56 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi Dan,
I just started work on updating my MIRA wrapper, and fell over a regression present of 6079:5e6254f2b9e3, steps to reproduce on Linux:-
1. Install latest Galaxy 2. Install my MIRA wrapper v0.0.1 from the tool shed (don't need MIRA for this) 3. Run Galaxy 4. Select the MIRA tool 5. Change "Backbones/reference chromosomes?" or "Sanger/Capillary reads?" or "454 reads?" or "Solexa/Illumina reads?" to yes 6. Instead of new file parameter appearing, get a KeyError: '__current_case__' exception (details below).
Shorter example without a 3rd party tool:
1. Install latest Galaxy 2. Run Galaxy 3. Select the "Convert SOLiD output to fastq" tool 4. Change "Is this a mate-pair run?" to yes 5. Instead of new file parameters appearing, get a KeyError: '__current_case__' exception.
By going through recent commits and retesting, I found the commit which caused this regression:
changeset: 6078:894112e0b9d5 user: Daniel Blankenberg <dan@bx.psu.edu> date: Thu Jun 09 11:26:41 2011 -0400 summary: Some fixes for interplay between DataToolParameter, implicit datatype conversion and dynamic select lists. Closes #491.
I guess there are downsides to running my development environment off galaxy-central rather than galaxy-dist ...
Peter
This has been fixed as of 6116:124f8bcea0ff but I didn't bother to work out which change solved it. Regards, Peter
Hi Peter, If you were curious it was fixed about 7 hours later in 5681:0886ed0a8c9f Thanks for using Galaxy, Dan On Jun 16, 2011, at 4:32 AM, Peter Cock wrote:
On Wed, Jun 15, 2011 at 4:56 PM, Peter Cock <p.j.a.cock@googlemail.com> wrote:
Hi Dan,
I just started work on updating my MIRA wrapper, and fell over a regression present of 6079:5e6254f2b9e3, steps to reproduce on Linux:-
1. Install latest Galaxy 2. Install my MIRA wrapper v0.0.1 from the tool shed (don't need MIRA for this) 3. Run Galaxy 4. Select the MIRA tool 5. Change "Backbones/reference chromosomes?" or "Sanger/Capillary reads?" or "454 reads?" or "Solexa/Illumina reads?" to yes 6. Instead of new file parameter appearing, get a KeyError: '__current_case__' exception (details below).
Shorter example without a 3rd party tool:
1. Install latest Galaxy 2. Run Galaxy 3. Select the "Convert SOLiD output to fastq" tool 4. Change "Is this a mate-pair run?" to yes 5. Instead of new file parameters appearing, get a KeyError: '__current_case__' exception.
By going through recent commits and retesting, I found the commit which caused this regression:
changeset: 6078:894112e0b9d5 user: Daniel Blankenberg <dan@bx.psu.edu> date: Thu Jun 09 11:26:41 2011 -0400 summary: Some fixes for interplay between DataToolParameter, implicit datatype conversion and dynamic select lists. Closes #491.
I guess there are downsides to running my development environment off galaxy-central rather than galaxy-dist ...
Peter
This has been fixed as of 6116:124f8bcea0ff but I didn't bother to work out which change solved it.
Regards,
Peter
On Thu, Jun 16, 2011 at 2:23 PM, Daniel Blankenberg <dan@bx.psu.edu> wrote:
Hi Peter,
If you were curious it was fixed about 7 hours later in 5681:0886ed0a8c9f
Thanks for using Galaxy,
Dan
Thanks - I know this kind of unexpected breakage is inevitable sometimes, but would recommend tool developers in general run with galaxy-dist or galaxy-central? Peter
Hi Peter, Production servers, or any server where you have users, should always track Galaxy-dist. Galaxy-central is a development repo (you get access to the "latest and greatest", but also should Expect more bugs to pop up at any given time), from the Galaxy-central header on bitbucket: "Main development repository for Galaxy. Active development happens here, and this repository is thus intended for those working on Galaxy development. See http://bitbucket.org/galaxy/galaxy-dist/ for a more stable repository intended for end-users." Its really a personal choice that each (tool) developer will have to make based upon whether they consider themselves to be a pure end-user (just adding tools or running a Galaxy server) who only wants to work on a "stable" branch; or if they want to contribute to Core development or gain early access to development features (and bugs). I would say that finalized tools and e.g. tools submitted to the tool shed should be vetted against galaxy-dist. Thanks for using Galaxy, Dan On Jun 16, 2011, at 9:26 AM, Peter Cock wrote:
On Thu, Jun 16, 2011 at 2:23 PM, Daniel Blankenberg <dan@bx.psu.edu> wrote:
Hi Peter,
If you were curious it was fixed about 7 hours later in 5681:0886ed0a8c9f
Thanks for using Galaxy,
Dan
Thanks - I know this kind of unexpected breakage is inevitable sometimes, but would recommend tool developers in general run with galaxy-dist or galaxy-central?
Peter
On Thu, Jun 16, 2011 at 3:01 PM, Daniel Blankenberg <dan@bx.psu.edu> wrote:
Hi Peter, Production servers, or any server where you have users, should always track Galaxy-dist.
Yes, that's very clear.
Galaxy-central is a development repo (you get access to the "latest and greatest", but also should Expect more bugs to pop up at any given time), from the Galaxy-central header on bitbucket: "Main development repository for Galaxy. Active development happens here, and this repository is thus intended for those working on Galaxy development. See http://bitbucket.org/galaxy/galaxy-dist/ for a more stable repository intended for end-users." Its really a personal choice that each (tool) developer will have to make based upon whether they consider themselves to be a pure end-user (just adding tools or running a Galaxy server) who only wants to work on a "stable" branch; or if they want to contribute to Core development or gain early access to development features (and bugs). I would say that finalized tools and e.g. tools submitted to the tool shed should be vetted against galaxy-dist.
OK, that's basically how I've been working - quite often during tool development I've hit bugs in Galaxy and wanted to make branches with fixes etc, or needed new functionality for a tool that isn't yet in galaxy-dist. Peter
participants (2)
-
Daniel Blankenberg
-
Peter Cock