getNewUUID(uuidfunc) returns badly formatted guid value

Agent Code
1

My code stopped working recently and the cause is a badly formatted uuid value from the utilities.getNewUUID() function. the response does not indicate an error and the uuid value appears to contain a portion of the web page that actually produces the UUID from https://www.uuidgenerator.net/ rather than the value.

example response from the IMP utility:
span id=“generated-uuid” 8acab2

typical uuidgenerator.net source wrapped around the generated number:
span id=“generated-uuid”>f729f8f1-0994-450a-a50d-ea8cd6f7b540 span

I have coded a work-around for now that will start using the proper generated values when it returns a valid value, so not an emergency on my side to get this fixed.

if ((uuid.len() > 5) && (uuid.find(“span”) == null))
{
//… use it
}
else
{
// use this temporary value
local d = date(time() + ((timezone + dstz)6060)); // get the date in your timezone
local fguuid = format("%02d:%02d:%02d-%02d.%02d.%4d.%02dfg",d.hour,d.min,d.sec,d.month+1,d.day,d.year,utilities.rnd(9));
}

2

@terrencebarr should probably take a look at this as the libs come from his team

3

Thanks, will have a look!

4

There has been a change to the site from which the code sources the UUIDs. This has been fixed and tested, and there’s a pull request in. The #require version will then be updated.

5

When and how will we be notified the new version is available for general use ?

The source web site has failed in the past but recovered after a short period ( a day or so ), Since the source web site response actually changed this time, will this function be included in the general monitoring of functionality in the future ?

Thank you.

6

We’ll mention it here, but we encourage all library users to check the Dev Center regularly for information on new library versions — and for new libraries, for that matter.

Libraries are provided on a free basis to all our users, so while we endeavour to ensure they remain up to date, we can’t commit to doing so in every case. If you discover an issue, you can report it here, or submit a pull request to the relevant GitHub repo.

7

I finally got around to trying the new version of the GUID function in utilities.lib.nut.2.0.0 and it appears to no longer accept the same callback function syntax as 1.0. The docs between 1.0 and 2.0 show the same function call format, but 2.0 does not show how to use the callback…, did the callback async aspect get dropped under 2.0 ? If it did then it must now be synchronous and what happens if a GUID generation fails ?

8

There is no callback (see the source here https://github.com/electricimp/Utilities/blob/master/utilities.lib.nut ).

Instead of calling an external service, this just generates an RFC compatible UUID internally - hence it will return immediately and there’s no need for an async call.

9

The prototype on this page shows it still uses a callback function, the library code does not support that ability and because of that it does not work without making code modifications to any existing code calling it, a little pain at first to figure that fact out…
The web site that used to generate globally unique id appears to be down right now as well.
https://www.uuidgenerator.net/
I am pretty sure that site made globally unique values, the 2.0 utilities does not actually generate a phrase that will never occur again ( however unlikely ) as far as I can tell.

10

I added the old library functions to my own code base so that i can still have the callback prototype with a Type 1 value and a Type 4 value if the web site fails or is down for maintenance…

// **********  UUID Accessor Function  **********
// **********         Public           **********
__getNewUUID <- function(cb = null) {
    if (cb == null) {
        server.error("getNewUUID() requires a callback function with err, data parameters");
        return;
    }

    ::__uuidcb <- cb;
    http.get("https://www.uuidgenerator.net/version1").sendasync(__extractUUID);
}

// **********         Private          **********
// <span id="generated-uuid">26ce3c61-3875-4ee5-9d73-3d3a7ecd03c3</span>
__extractUUID <- function(rs) {
    local u = "";
    if (rs.statuscode == 200) {
        if (rs.body.len() > 0) {
            for (local i = 0 ; i < (rs.body.len() - 20) ; ++i) {
                local s = rs.body.slice(i, i + 20);
                if (s == "id=\"generated-uuid\">")
                {
                    u = rs.body.slice(i + 20, i + 56);
                    break;
                }
            }

            ::__uuidcb(null, u);
        }
    } else {
        ::__uuidcb("Type4", utilities.getNewUUID());
    }
}
11

I mean, when it’s that many bits of random I don’t think you need to worry so much - obviously this will depend on your request rate, use of the UUID etc. There are inherent risks with relying on random uuid generator services, but your approach of falling back if it’s not available seems sensible.

12

This is why we changed the library to remove that dependency.

13

Coding in ways to prevent catastrophic failure is always a good goal, accurate documentation also helps prevent frustration. The prototype in the new library documentation is not correct and apparently is not caught during compile checks in the code UI but does eventually cause an IMP agent error 500 response in my scenario when it finally gets called, nothing logged…

utilities.getNewUUID( callback ) should be utilities.getNewUUID( ) for the lib 2.0 version

14

That’s updated on the Dev Center and in the repo. I also took the opportunity to fix a missing bracket in the example code.