Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cleanup Vumi bridge and add Junebug support #1028

Merged
merged 18 commits into from
Mar 30, 2016

Conversation

KaitCrawford
Copy link
Contributor

No description provided.

@@ -65,7 +64,7 @@ def get_next_request(self):

class TestGoConversationTransport(TestGoConversationTransportBase):

transport_class = GoConversationClientTransport
transport_class = GoConversationTransport
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to delete these old client transport tests. They're not failing currently because they're accidentally not being run (because the both this class and the server test class are now called TestGoConversationTransport).

@hodgestar
Copy link
Contributor

Left two small comments, and we need to look at why tests are failing, but otherwise looks good.

@hodgestar
Copy link
Contributor

Given that unrelated middleware tests are failing for all builds except the one pinned to Twisted 13.2, I suspect this indicates more tests broken by Twisted 16.0.

@rudigiesler
Copy link
Contributor

@hodgestar Looking at the middleware tests that are failing, looks like there's a twisted import (to do with ssh), that if it fails, the tests aren't run. So it's very possible that the latest twisted fixed that module import, and that test has been broken for a very long time. (Either way, completed unrelated to this PR).

@hodgestar
Copy link
Contributor

Creating #1029 to deal with the manhole middleware test failures.

@KaitCrawford
Copy link
Contributor Author

@hodgestar @rudigiesler Please give this another look.
I'm not sure the last commit is what you meant hodgestar, I might be misunderstanding how web_path gets used.
I also think I should probably be updating the status in more places but I'm struggling to identify where.

@hodgestar
Copy link
Contributor

@KaitCrawford Could you merge develop into this branch so we can check if tests pass?

published status.'''
if self.status_detect.check_status(**kw):
yield self.publish_status(**kw)
# TODO: Notify Junebug
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The line above notifies Junebug, so we can remove this TODO. :)

@hodgestar
Copy link
Contributor

Other than removing the TODO, looks good to me!

@KaitCrawford
Copy link
Contributor Author

Really? \o/ whoohooo!

@rudigiesler
Copy link
Contributor

Looks good to me too. 👍

@hodgestar
Copy link
Contributor

Oh, I realized something -- do we want to add status events for inbound messages too? Just "good" if we receive a valid request and "bad" if we receive a broken request?

@hodgestar
Copy link
Contributor

I also remembered that we wanted to only publish acks once we received an ack from Vumi Go (so publish a nack if submitting the message to Vumi Go fails and then publish whatever event Vumi Go gives us).

@hodgestar
Copy link
Contributor

Maybe this means we should also re-think the components a bit. Maybe we want separate components for http-requests-to-vumi-go, http-requests-from-vumi-go and events-from-vumi-go (except with better names)?

@KaitCrawford
Copy link
Contributor Author

@hodgestar the names are probably still horrible :)

def add_status_bad_req(self, component):
return self.update_status(
status='down', component=component, type='bad_request',
message='Bad request received')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to set type and message more appropriately for the different error / success cases (e.g. Bad request received is not correct when we're failing to make requests).

Maybe this means that add_status_good_req and add_status_bad_req should be removed? Or maybe we should have a pair of these methods for each kind of status update?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a pair of them for each kind of status update at this point seems a bit much to me. I vote for removing them rather

@hodgestar
Copy link
Contributor

Idea for better status component names:

  • http-requests-to-vumi-go -> submitted-to-vumi-go
  • http-requests-from-vumi-go -> received-from-vumi-go
  • events-from-vumi-go -> sent-by-vumi-go

Thoughts?

@KaitCrawford
Copy link
Contributor Author

@hodgestar please re-review

@@ -134,6 +122,9 @@ def handle_outbound_message(self, message):
if resp.code != http.OK:
log.warning('Unexpected status code: %s, body: %s' % (
resp.code, resp.delivered_body))
self.update_status(
status='down', component='submitted-to-vumi-go',
type='bad_request', message='Bad request sent')
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe the message here should be Message submission rejected by Vumi Go. (since we don't know if the request was bad -- only that Vumi Go didn't accept it).

@KaitCrawford
Copy link
Contributor Author

@hodgestar updated again

self.update_status(
status='ok', component='sent-by-vumi-go',
type='vumi_go_sent', message='Sent by Vumi Go')
else:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Events could also be delivery reports, so we should do something like elif msg.payload["event_type"] == "nack" here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hodgestar Didn't we decide we weren't going to handle delivery reports at this juncture? Although if this is all that's required I'm happy to add them.
What would a nack event_type mean and what should we do when we receive them?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hodgestar
Copy link
Contributor

Left what I hope are the last two minor comments!

@KaitCrawford
Copy link
Contributor Author

@hodgestar ready for another round

@hodgestar
Copy link
Contributor

👍 🍰

Also, I am honoured to present @KaitCrawford with The Monthly 🐫 Trophy for continuing with this PR all the way to the end!

@KaitCrawford
Copy link
Contributor Author

what is a 🐫 trophy and should I be scared?

@KaitCrawford KaitCrawford merged commit 767f507 into develop Mar 30, 2016
@hodgestar
Copy link
Contributor

It is a trophy for successfully crossing the desert. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants