I'm going to mark this as resolved, since:

• The S3 use case is more or less moot, since S3 was turned into a real Future after I got tired of dealing with the dependency.
• D21038 does the actual thing, at least more or less.

I think "keep stuff out of the trace" is a reasonable use case, but I'd like to revisit it if it's still relevant after T13490 resolves, since that's likely to change how this this kind of instrumentation (which I'm assuming is like "how often do users run arc diff, and how fast is it?") works. I currently imagine integrating Arcanist workflows into ServiceProfiler by default, so the fix to this issue might be something like:

• Define a formal "report" phase for ServiceProfiler, which is the time we spend inside endServiceCall().
• When we enter the report phase, set a flag to ignore reentrant calls back into ServiceProfiler (so they don't appear in the trace, etc).
• When we exit the report phase, clear the flag. Report the "report" cost in the final echo trace.

So the default trace would go from looking like this:

>>> [26] (+736) <http> https://secure.phabricator.com/api/differential.query
>>> [27] (+382) <http> https://tracker.mycompany.com/

...to something like this:

>>> [26] (+736 / 382) <http> https://secure.phabricator.com/api/differential.query

Where the "/ 382" means "we spent 382ms reporting/processing the event" in ServiceProfiler. That would still provide a hint that your reporting is a bottleneck if you see a big number there, but wouldn't gum up the trace, and would allow extensions against ServiceProfiler to freely do things which require service invocations without reporting themselves.