When you see
TransactionActivity@7fffffff it often means the agent traced a Transaction activity that turned out to be not related to a specific Transaction. It is fairly common and most of the time is not an issue.
One thing I often do when I’m running down a Transaction is to locate the ID, such as
Transaction@2ce7ba1d, I grep the log for the ID to get an overview of the activity.
You can also see in the  (square brackets] two integers. One is the pid and one is the tid. These can also be used to filter for specific activity.
Based on what I’m seeing from the logging you provided and the opcode 176, which is the result when a transaction is ignored or when it fails, I can see the reason behind one of them.
restapi_1: Nov 18, 2019 13:24:39 +0000 [122 1334] com.newrelic FINER: Transaction com.newrelic.agent.Transaction@2ce7ba1d: ignoring link call because transaction already on thread.
Async activity can lead to some unexpected behavior if the call goes outside of the visibility of the agent. I have frequently used an analogy of going on a blind date and your date excuses themselves to the restroom but is gone for an extraordinary amount of time. You are left wondering, not only if they are okay but should you wait for them because if they bolted out a back door or window and you don’t know it, you could be waiting for a very long time.
The design of the agent includes logic where it waits for a specific time before it discards an activity as well because if the agent waits until a response is given, the response time could be an outrageous value. If there is a great deal of async activity, the resources in Memory/CPU/Threads being held up in the waiting could possibly impact the application detrimentally.
Let us know if this information is helpful.