From da51c55410d39a731ba35de90f7c3219547f6170 Mon Sep 17 00:00:00 2001 From: Jason Volk Date: Fri, 30 Nov 2018 13:00:16 -0800 Subject: [PATCH] modules/federation/invite: Commentary; minor cleanup. --- modules/federation/invite.cc | 32 ++++++++++++++++++++++++++------ 1 file changed, 26 insertions(+), 6 deletions(-) diff --git a/modules/federation/invite.cc b/modules/federation/invite.cc index befb344d9..7aafca173 100644 --- a/modules/federation/invite.cc +++ b/modules/federation/invite.cc @@ -91,31 +91,51 @@ put__invite(client &client, signatures(sigs, event) }; - const json::strung revent{signed_event}; - const json::value response[2] + const json::strung revent { - json::value { 200L }, + signed_event + }; + + const json::value array[2] + { + json::value + { + 200L + }, json::members { { "event", revent } } }; - resource::response + // Send back the signed event first before eval. If we eval the signed + // event first: the effects will occur before the inviting server has + // the signed event returned from us; they might not consider the user + // invited yet, causing trouble for the eval effects. That may actually + // still happen due to the two separate TCP connections being uncoordinated + // (one for this request, and another when m::eval effects connect to them + // and make any requests). But either way if this call fails then we will + // lose the invite but that may not be such a bad thing. + resource::response response { client, json::value { - response, 2 + array, 2 } }; + // Eval the dual-signed invite event. This will write it locally. This will + // also try to sync the room as best as possible. The invitee will then be + // presented with this invite request in their rooms list. m::vm::opts vmopts; m::vm::eval { signed_event, vmopts }; - return {}; + // note: returning a resource response is a symbolic/indicator action to + // the caller and has no real effect at the point of return. + return response; } resource::method