aarronc / hutton-helper

data collection tool to aid in better management of the BGS
9 stars 4 forks source link

local chat window commands not showing up when executed #55

Closed aarronc closed 6 years ago

aarronc commented 6 years ago

when I look at best Hutton run for example it fires off a POST instead of a GET for that info. when typing in any of the other ones in the local.py it triggers the GET or POST but does not update the text line in the helper: section. I can't put my finger on it :(

sporebat commented 6 years ago

Back when we had a chain of if statements rather than lookup tables, some of the local commands used GET and others used POST. I was pretty sure all the ones with {cmdr} in the format stri...

Damnit, there's no emoji here suitable for a sporebeast blushing with embarrassment.

                command_xmit_path = self.xmit_paths.get(command)
                if command_xmit_path:
                    command_xmit_path = command_xmit_path.format(cmdr=cmdr, system=system)
                    if '{cmdr}' in command_xmit_path: # FILTHY hack to figure out if it's a 'get'
                        json_data = xmit.get(command_xmit_path)
                    else:
                        json_data = xmit.post(command_xmit_path, data=transmit_json, headers=xmit.COMPRESSED_OCTET_STREAM)

                if not json_data:
                    command_status_format = 'Failed to Send {command} Command'

We call command_status_format.format when using it. Great! We also call command_xmit_path.format when using it. Great! But, we assign the result back to itself. Which means that the check for '{cmdr} can't possibly work. So, every command gets a POST.

sporebat commented 6 years ago

Sorry about the thrash, there.

Remaining problem with local.py: not all server methods return JSON, so I'm never sure whether not getting any JSON back means something went wrong or not (#57). In turn, I'm reporting Failed to Send {command} Command sometimes when the server might well be happy.

Zooming out: I'm returning None from xmit when there are problems, not throwing an exception. That might not be such a good idea, as it's hard to distinguish from the None when everything went fine but there was no data. If you get #57 done, I'll have it return something like True so people can test for isinstance(json_data, dict) to see if it's meaty.

Why not object?

Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:22:17) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> isinstance(True, object)
True

Back to the story: as well as accepting #56 if it helps more than it hurts, delete this conditional if most of the commands don't need a response:

                if not json_data:
                    command_status_format = 'Failed to Send {command} Command'
sporebat commented 6 years ago

Trying a horrible hack: an xmit.FAILED global that's False most of the time and True if we got bad JSON for a 200 or anything other than a 200 or 204.