I have a service file foo.service that is configured to auto-start after a target init_done.target.

[Unit]
After=init_done.target
...
[Install]
WantedBy=multi-user.arget

If I run systemctl stop foo.service before foo.service is ready (i.e., init_done.target has become active), a message can be seen in the log: "Stopped Foo Service."

systemctl status foo
● foo.service - Foo Service
   Loaded: loaded (/etc/systemd/system/foo.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

Feb 12 01:23:45 user systemd[1]: Stopped Foo Service.

I presumed this systemctl stop command is a no-op, because foo.service has yet to become active which means there is nothing to stop.

However, it turns out that running the systemctl stop foo.service command this early on in the boot sequence actually prevents foo.service from starting even when init_done.target eventually becomes active. This is surprising to me because I thought using systemctl stop in this manner should be a no-op as I explained above. Is this the expected behavior? And where can I find documentation on this? I've read through the man page and can't find a direct answer on what should happen when systemctl stop is used on an inactive target that is configured to auto-start after a specific target becomes active.

For the record, the systemctl in question is on version 229.