(Yes, this looks familiar. It's the same debugging session as 'runs when started'. Be patient for heaven's sake.)
I grabbed some boilerplate off the web to make my systemd timer/service pair work. Worked fine.
systemctl enable myThing.timer
systemctl enable myThing.service
systemctl start myThing.timer
#do not start myThing. service or it will run immediately, that's ok at some other time for a special non-timer purpose.
I started my debugging with a quick script that just logged hello and it all worked quite nicely.
What I didn't notice initially is that it was running the target service when I started the timer.
Later, I changed it to refer to my real, long-running (hours) process and, as you might imagine, that made it very clear that it was being run an extra time.
The problem is that my boilerplate had a 'Requires' statement in the Unit stanza. When this is around, systemd does a 'start' on that Require'd process when the timer is started.
The Require statement I copied said...
Requires=myThing.service (just like it had Unit=myThing.service in the Timer stanza)
Turns out that systemd starts the Require'd service if it is not already running in case, I suppose, you forgot to.
The only reason I can imagine having the target process in the Require statement is so that it runs once at startup. I don't know but, there you have it. If you are getting extra invocations of your service, get it out of the Require statement.