Lock weirdness

[Bob_Zimmerman]

Currently using APIv1.7.1, and I've noticed some weird behavior with write locks on objects. When I make a call to change an object like so:

mgmt_cli -s session.txt -f json set host uid f752bfcd-8194-4831-a8cf-16dabecbac73 ipv4-address 10.20.30.40

the data returned by the call includes meta-info.lock: "unlocked" and read-only: true. When I later show the same object from the same session like so:

mgmt_cli -s session.txt -f json show host uid f752bfcd-8194-4831-a8cf-16dabecbac73

the data returned has meta-info.lock: "locked by current session" and read-only: false.

Why the difference?

Separately, is there a way in the API to see which objects have a lock besides just downloading everything from scratch? 'show sessions' for the session with the lock shows it has a lock, but doesn't tell you what it has locked. Specifically, I want to be able to tell what objects have been locked since I started my session, and which sessions have locked them.

[PhoneBoy]

Paging @Omer_Kleinstern 

[Bob_Zimmerman]

Coming back to this, I put together a brief script demonstrating the issue:

[Expert@DallasSA]# mgmt_cli -r true login > session.txt
[Expert@DallasSA]# UUID_TO_CHANGE=$(mgmt_cli -f json -s session.txt show hosts limit 1 | jq '.objects[0].uid')
[Expert@DallasSA]# mgmt_cli -f json -s session.txt show host uid "$UUID_TO_CHANGE" details-level full | jq '{readOnly:."read-only",metaInfo:."meta-info"}';mgmt_cli -f json -s session.txt set host uid "$UUID_TO_CHANGE" comments "Testing a change" details-level full | jq '{readOnly:."read-only",metaInfo:."meta-info"}';mgmt_cli -f json -s session.txt show host uid "$UUID_TO_CHANGE" details-level full | jq '{readOnly:."read-only",metaInfo:."meta-info"}'
{
  "readOnly": false,
  "metaInfo": {
    "lock": "unlocked",
    "validation-state": "ok",
    "last-modify-time": {
      "posix": 1637433240653,
      "iso-8601": "2021-11-20T18:34+0000"
    },
    "last-modifier": "WEB_API",
    "creation-time": {
      "posix": 1637433240653,
      "iso-8601": "2021-11-20T18:34+0000"
    },
    "creator": "WEB_API"
  }
}
{
  "readOnly": true,
  "metaInfo": {
    "lock": "unlocked",
    "validation-state": "ok",
    "last-modify-time": {
      "posix": 1666550291300,
      "iso-8601": "2022-10-23T18:38+0000"
    },
    "last-modifier": "WEB_API",
    "creation-time": {
      "posix": 1637433240653,
      "iso-8601": "2021-11-20T18:34+0000"
    },
    "creator": "WEB_API"
  }
}
{
  "readOnly": false,
  "metaInfo": {
    "lock": "locked by current session",
    "validation-state": "ok",
    "last-modify-time": {
      "posix": 1666550291300,
      "iso-8601": "2022-10-23T18:38+0000"
    },
    "last-modifier": "WEB_API",
    "creation-time": {
      "posix": 1637433240653,
      "iso-8601": "2021-11-20T18:34+0000"
    },
    "creator": "WEB_API"
  }
}

Still on API v1.7.1 (R81 jumbo 74).

The main command generates a before-change output, the output from the change call, then an after-change output. The change output updates the read-only property to true, and the meta-info.last-modify-time gets updated, but the meta-info.lock property stays "unlocked". Then immediately after the change, the read-only property goes back to false and the meta-info.lock updates to say it's locked by the current session.

Is this expected behavior? Seems weird to not immediately show the object is locked by the current session. The brief trip through read-only: true is also strange.

[PhoneBoy]

Sounds weird to me also.
@Omer_Kleinstern 

[Omer_Kleinstern]

Looks like an issue.

Why is this property interesting in this case? When a SET command on a network object is completed successfully, the object is definitely locked by the current session.

[Bob_Zimmerman]

It's only really an issue because I would like my data import to be simple. I want to avoid special cases like "I just set this object, so ignore the meta-info fields the returned data has, and use this meta-info I create locally instead."

The language I'm using is aggressively asynchronous and reactive. All of my response handling (and therefore data importing) is in a callback closure, which doesn't necessarily get to know about the request which resulted in the closure being called. I can spin up a background thread and force a synchronous call (thereby maintaining access to call input), but that's gross for other reasons. Still, might be my best option for now.

The language is also strongly-typed, which makes the wide assortment of objects returned by 'show objects' interesting to handle, but that's pretty far off-topic. 😉