Unable to subscribe to event stream with Diplomat::Event

[ryansch]

For my use case I want to treat the consul events like an event stream and get the newest one or sleep until a new event arrives. However, both .get and .get_all appear to drop the current newest event if run with :wait, :wait. This means that I can either get the latest event or choose to possibly drop an event and wait for a new one.

Here's some ruby code that does what I want:

response = Excon.get(
  URL,
  query: {name: EVENT},
  expects: [200],
  connect_timeout: 5,
  read_timeout: 5,
  write_timeout: 5,
  tcp_nodelay: true
)

handle_events(response.body)

loop do
  index = response.headers['X-Consul-Index']
  response = Excon.get(
    URL,
    query: {name: EVENT, index: index},
    expects: [200],
    connect_timeout: 5,
    read_timeout: 86400,
    write_timeout: 5,
    tcp_nodelay: true
  )

  handle_events(response.body)
end

I then sift the newest event against a consul key that stores the last event LTime I worked off.

I expected to be able to use Diplomat to solve this problem.

[johnhamelink]

Sorry for the huge wait time for a response for this - I've been super busy!

So from what I've read, the issue you're having is that the wait command skips the current event. That makes sense to me - the command is not supposed to send multiple results back and if it returned the current event it'd never wait for a new one. So it sounds like what you need to do is wrap Diplomat in a function that retrieves the current result and then drops into a loop of waiting.

Is that helpful?

JH

[ryansch]

@johnhamelink I already have a working example above. I was just pointing out that the mechanics of how Diplomat currently deals with events doesn't lend itself to treating it like an event stream where I can just handle each event as it comes in.

[johnhamelink]

@ryansch yeah, I get that now 😄 I guess there isn't really all that much that can be done though without massively increasing the complexity of Diplomat. The best thing in my opinion would be to write this functionality in another gem that depends on diplomat.