One general question I have -- the new UUID gets inserted into query_options, but what does it do there...

Okay, Andy just stopped by and explained that the point is that the transaction_uuid ends up part of the indirected request for the catalog, recorded as a query parameter in the uri, and since puppetdb has access to the request, it can see that uuid in the uri and tie it to the uuid we're explicitly putting into the Report instance.

So, that makes sense, but the fact that the uuid gets recorded in the uri and is the piece of information being used to correlate is pretty mysterious just from looking at the Configurer code.

What if we wrapped this inclusion of the transaction_uuid in a method that described what it was doing?

    add_transaction_uuid_to_catalog_query_parameters(query_options)

Or, something similar?  And if the query_options are all translated as http query parameters by the indirector...perhaps query_options should be renamed?  Except the indirection is probably not guaranteed to be an http terminus.