Run cache_joined_hosts_for_event in background

[erikjohnston]

This is because sometimes redis can take a 50ms to respond, and there's no point blocking the request waiting for the responses.

[richvdh]

I gueessss, but doing this stuff without the proper logcontext management always makes me queasy.

Can we run it in parallel with the rest of handle_new_client_event ?

[richvdh]

Can we run it in parallel with the rest of handle_new_client_event ?

Or is the whole point that we want to return to the client before the redis request completes?

[erikjohnston]

I gueessss, but doing this stuff without the proper logcontext management always makes me queasy.

Oh, right, we want to only use run_in_background when we know it won't outlive the logcontext? (I feel like I keep running into this, where I want to spin off some work that is to do with a particular context, but shouldn't block the request.)

Can we run it in parallel with the rest of handle_new_client_event ?

Or is the whole point that we want to return to the client before the redis request completes?

Do you mean effectively doing gatherResults(handle_new_client_event, cache_joined_hosts)? I think that would probably be fine as doing the cache_joined_hosts really should be quicker than persisting the event.

[richvdh]

Oh, right, we want to only use run_in_background when we know it won't outlive the logcontext?

Ideally, yes. If it might outlive the logcontext then the idea is you use run_as_background_process to make sure it gets its own logcontext and metrics. But that's a bit heavier weight, obvs.

Do you mean effectively doing gatherResults(handle_new_client_event, cache_joined_hosts)

yes, exactly.

[richvdh]

if this fails do we want to cancel _persist_event (and swallow the result if it completes successfully)? Maybe give it a .errback which just logs the error?