Not sure whether this applies to all remote nodes or just to bundle nodes... presumably just bundle nodes or maybe guest nodes generally. The return value of `crm_get_peer_full(v->nodeid, v->nodename, CRM_GET_PEER_ANY)` is a `crm_node_t` with `uname` set but otherwise no `uuid`, no `crm_remote_node` flag set, no anything.
```
[root@pcmktest-bundle-0 /]# attrd_updater --name testattr --update false
[root@pcmktest-bundle-0 /]#
```
Same applies with `crm_attribute`, which makes the same API call.
The attribute update is written to attrd but is **not** written to the CIB. The logs on the host show:
```
Dec 08 22:29:46.686 fastvm-rhel-9-0-42 pacemaker-attrd [558604] (update_attr_on_host) notice: Setting testattr[pcmktest-bundle-0] in instance_attributes: (unset) -> false | from fastvm-rhel-9-0-42 with no write delay
Dec 08 22:29:46.687 fastvm-rhel-9-0-42 pacemaker-attrd [558604] (pcmk__get_peer) info: Created entry 53899250-391d-4001-930c-1e5441b11663/0x5636df853d40 for node pcmktest-bundle-0/0 (2 total)
Dec 08 22:29:46.687 fastvm-rhel-9-0-42 pacemaker-attrd [558604] (pcmk__corosync_uuid) info: Node pcmktest-bundle-0 is not yet known by Corosync
Dec 08 22:29:46.687 fastvm-rhel-9-0-42 pacemaker-attrd [558604] (pcmk__get_peer) info: Cannot obtain a UUID for node 0/pcmktest-bundle-0
Dec 08 22:29:46.687 fastvm-rhel-9-0-42 pacemaker-attrd [558604] (attrd_write_attribute) notice: Cannot update testattr[pcmktest-bundle-0]=false because peer UUID not known (will retry if learned)
```
I reverted the "CIB transaction in attrd" commit and this issue persisted, so this one (as opposed to T733) is not a recent regression from me :)