Cant get any feedback or any error even tho there is a problem

[evrenios]

using houston (2.2.1) ruby 2.1.2 and rails 4.1.4 i m sending push notification to the users but even tho i entered false device token it doesn't raise any notification error, and overtime when i try to use Feedback service it gives me an empty array.

notification = Houston::Notification.new(device: User.last.device_token) notification.alert = "Feedback test!" connection.write(notification.message) puts "Error: #{notification.error}." if notification.error

is it some kind of bug anything wrong in my side,

I can send the other notifications without a problem but i need to know if its not sent and the reason (the 10 feedback code of apple provides)

[lukasnagl]

This may be related to #83 and #79, but it is worth noting that multiple currently open issues would benefit from an implementation of notification.error more according to the expectations. I haven’t checked if this is due to Houston’s codebase, though. It may as well be because of some unexpected behavior of APNS.

[evrenios]

any update on this issue? I deliberately give wrong token and try to populate notification.error but its not working. While i was checking the available methods on notification i noticed "apns_error_code=" and to be exact this is what i want

notification.apns_error_code=8 => 8 2.1.2 :075 > notification.error => #

Is it a problem on my side?

for reference by problematic device token with empty alert (another problem on apns server to give feedback about)

2.1.2 :090 > notification => #<Houston::Notification:0x007fd0c5e5a9f0 @token="b2cf791e03e99a3efa7948ffc16cb388ce2893ea385d3854d6183a3593dc152a", @alert=nil, @badge=nil, @sound=nil, @category=nil, @expiry=nil, @id=0, @priority=nil, @content_available=nil, @custom_data={}, @sent_at=2015-01-11 23:21:35 +0200> 2.1.2 :091 > notification.error => nil

[judgetr]

any update on this issue ? @j4zz

[lukasnagl]

Not exactly, but we got a best-effort implementation for the moment based on https://github.com/nomad/houston/issues/72, which tries to send all notifications on a connection, and after it’s done, tries to read an error. If an error can be read, send all notifications after the erroneous one again.

The following snippet is ripped out from our actual implementation, so it’s untested, but should be sufficient to show the approach:

def notify(push_options = {}, tokens)
  return if tokens.empty?

  # Use new connections since the connection becomes unusable once
  # an invalid token was encountered
  connection = Houston::Connection.new(apns_gateway, apns_cert_file, apns_cert_pw)

  # Send notifications
  tokens.each_with_index do |token, index|
    notification = Houston::Notification.new(push_options.dup.merge({token: token, id: index}))
    connection.write(notification.message)
  end

  ssl = connection.ssl
  error_index = -42 # magic number for no error
  # Use a timeout (!) to try to read from the connection (notice the [] write_array parameter)
  read_socket, write_socket = IO.select([ssl], [], [ssl], 1)
  if (read_socket && read_socket[0])
    if error = connection.read(6)
      command, status, error_index = error.unpack("ccN")

      # Handle your error here (Error: #{status} with id: #{error_index} Token: #{tokens[error_index].token}")
    end
  end
  connection.close
  # Resend all notifications after the once that produced the error
  notify(push_options, tokens[(error_index+1)..-1]) if error_index != -42 #magic number for no error
end

What’s could be improved about this? It relies on a timeout to wait for an error, and it is inefficient if the invalid tokens are hit early on or repeatedly.

Generally, I get the feeling that this is largely ignored because it mostly happens if you mangle your development tokens with production tokens in your deployment environments and there seems to be no perfectly clean solution without performance impacts. Feel free to provide some insight, though. :)

[ferrous]

A lazy wrap with reset on CLOSE_WAIT connections (working on linux) https://gist.github.com/ferrous/d498971be300683c3bbd

[bscofield]

@evrenios one note on this: you're writing to the connection directly, but notification.error is only set if you're using an instance of Houston::Client. (And yes, I know this issue is almost a year old :smile:)