Clean up some logging

[richvdh]

This just makes some of the logging easier to follow when things start
going wrong.

[erikjohnston]

Why remove the prefixing? I find it quite useful to track how we're processing an event?

[richvdh]

because it's in the logcontext anyway.

[erikjohnston]

Oh, so it is. I had forgotten the log context isn't the generic request one. Carry on.

[erikjohnston]

I'd be tempted to not include e and rely on the exception chaining (raise Exception(..) from e).

(I assume we've checked that get_missing_events_for_pdu doesn't raise any expected exceptions.)

[richvdh]

I'd be tempted to not include e and rely on the exception chaining (raise Exception(..) from e).

I tried that. It made for remarkably unreadable errors, not least because the exception chain is epic.

Exception chaining happens by default when you raise an exception from an except block, afaik

[richvdh]

(I assume we've checked that get_missing_events_for_pdu doesn't raise any expected exceptions.)

well: first, I've looked at the places on_receive_pdu is called (ie, the places that might care that we turn one sort of exception into a generic Exception). There are two such places: _handle_queued_pdus, in which all exceptions are treated equally, and get_missing_events_for_pdu (again), which does treat FederationError with code=403 specially.

Then going down through get_missing_events_for_pdu, the only things which might raise a FederationError are federation_client.get_missing_events (which I'm 99% sure doesn't), and on_receive_pdu which, as discussed, filters out such exceptions. So I'm reasonably confident it's not possible for get_missing_events_for_pdu to raise a FederationError with code=403, and therefore this change shouldn't make any difference.

[erikjohnston]

Up to you about using raise .. from ..

[richvdh]

oh, another thing that's worth noting about relying on the exception chaining:

the exception message here actually ends up getting sent back to the sending server. So for example:

{
  "pdus": {
    "$gTbOW9yxHJ9SkILmPz42b5t_NpN2XnD5Dk_SO_7cCBM": {
      "error": "Error fetching missing prev_events for $gTbOW9yxHJ9SkILmPz42b5t_NpN2XnD5Dk_SO_7cCBM: 404: Could not find event $-xeoZouRJKbRQ_MoNe5hff5gzaumxzIwcfscKgAtQy8"
    }
  }
}

There are other bugs that mean that error is completely bogus ($-xeo actually failed auth, rather than being missing), but it's progress in the right direction imho