Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Bob_Zimmerman
Authority
Authority

UUIDs are Case-Sensitive?

It looks like in some calls (at least /show-task), the UUID is case-sensitive:

[Expert@TestSC:0]# taskId="01234567-89ab-cdef-a755-0ba545d712b8"

[Expert@TestSC:0]# mgmt_cli -f json -s session.txt show task task-id "${taskId}"
{
  "tasks" : [ {
    "task-id" : "01234567-89ab-cdef-a755-0ba545d712b8",
    "task-name" : "Publish operation",
    "status" : "succeeded",
    "progress-percentage" : 100,
    "suppressed" : false,
    "task-details" : [ {
      "publishResponse" : {
        "numberOfPublishedChanges" : 1,
        "mode" : "async"
      },
      "revision" : "1d0ee167-f660-4f35-b810-2347e04970d7"
    } ]
  } ]
}

[Expert@TestSC:0]# mgmt_cli -f json -s session.txt show task task-id "${taskId^^}"
{
  "code" : "generic_err_object_not_found",
  "message" : "Requested object [01234567-89AB-CDEF-A755-0BA545D712B8] not found"
}

The ^^ in the second command just converts letters in the string to uppercase. UUIDs are 128-bit numbers, not really strings, so this seems likely to be unexpected behavior.

0 Kudos
4 Replies
Bob_Zimmerman
Authority
Authority

Can't seem to edit posts, and I realized I forgot to include the version I'm running. That system was R81.20 jumbo 65. I just rebuilt it at R81.20 jumbo 76 and I have the same issue:

[Expert@TestSC:0]# taskId="01234567-89ab-cdef-81cd-95e826bd7d4e"

[Expert@TestSC:0]# mgmt_cli -f json -r true show task task-id "${taskId}"      
{
  "tasks" : [ {
    "task-id" : "01234567-89ab-cdef-81cd-95e826bd7d4e",
    "task-name" : "Publish operation",
    "status" : "succeeded",
    "progress-percentage" : 100,
    "suppressed" : false,
    "task-details" : [ {
      "publishResponse" : {
        "numberOfPublishedChanges" : 1,
        "mode" : "async"
      },
      "revision" : "9485f8cb-4e2f-400f-88a7-9bf60c33e4a9"
    } ]
  } ]
}

[Expert@TestSC:0]# mgmt_cli -f json -r true show task task-id "${taskId^^}"
{
  "code" : "generic_err_object_not_found",
  "message" : "Requested object [01234567-89AB-CDEF-81CD-95E826BD7D4E] not found"
}

But this gets weirder. I also have an opposite issue:

[Expert@TestSC:0]# taskId=$(mgmt_cli -f json -s session.txt show tasks limit 1 | jq '.tasks[0]."task-id"' | tr -d '"')

[Expert@TestSC:0]# echo "${taskId}"
01234567-89ab-cdef-9c69-3d76e924acd1

[Expert@TestSC:0]# mgmt_cli -f json -s session.txt show task task-id "${taskId}"
{
  "tasks" : [ ]
}

[Expert@TestSC:0]# mgmt_cli -f json -s session.txt show task task-id "${taskId^^}"
{
  "tasks" : [ {
    "task-id" : "01234567-89ab-cdef-9c69-3d76e924acd1",
    "task-name" : "add simple-cluster",
    "status" : "succeeded",
    "progress-percentage" : 100,
    "suppressed" : true
  } ]
}

With that task, the lowercase string representation of the UUID doesn't throw an error, but it doesn't find the task. The uppercase string representation finds the task. So for some types of task, you need to specify the task ID in uppercase. For some, you need to specify it in lowercase.

0 Kudos
the_rock
Legend
Legend

Customer asked this exact question on totally unrelated TAC call once and Tier 3 confirmed they are indeed case sensitive. This was back in R81 base, but Im sure its still the same.

Andy

0 Kudos
Bob_Zimmerman
Authority
Authority

I really need to look at the database directly some time, because that's beyond weird. How are we supposed to use /show-task if it doesn't do any kind of data normalization and it returns different results like this?

In my last example, it doesn't even accept the task ID in the exact form which it just gave me a second or two earlier.

0 Kudos
PhoneBoy
Admin
Admin

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events