rfl::UUIDv4 field fails JSON parse in struct even for valid UUID

[RampantDespair]

Hi

I’ve run into what looks like a bug with the built-in rfl::UUIDv4 pattern type when it’s used directly as a struct field.

Minimal repro (GoogleTest)

#include <gtest/gtest.h>
#include <rfl/json.hpp>
#include <rfl/patterns.hpp>

struct Request {
    rfl::UUIDv4                id;
    std::string                command;
    std::optional<std::string> payload;

    static inline auto fromJson(std::string_view v) {
        return rfl::json::read<Request>(v);
    }
};

TEST(RequestParsing, UuidV4FieldFails) {
    const char *js = R"({
      "command":"PING",
      "id":"f23b2a1d-b1a6-4e0d-af1b-8f0d912e255a"
    })";

    auto req = Request::fromJson(js);

    // This *should* succeed because the UUID is valid v4, but it fails.
    EXPECT_TRUE(req.has_value())
        << "Parse failed: " << (req ? "" : req.error().what());
}

Observed behavior

The test fails with:

Parse failed: Failed to parse field 'id': String 'f23b2a1d-b1a6-4e0d-af1b-8f0d912e255a' did not match format 'UUIDv4': '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-4[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$'

…but the UUID clearly matches the regex.

Expected behavior

The JSON should parse successfully.

[liuzicheng1987]

@RampantDespair , I cannot reproduce the issue:

#487

As you can see, I have added a test for exactly the string you provided and it passes just fine on all tested operating systems and with all tested compilers.

[liuzicheng1987]

@RampantDespair , what version of CTRE are you using?

[RampantDespair]

@liuzicheng1987 I didn't install it directly, it's transitive from reflectcpp, here is the version:

$ vcpkg list | findstr /i ctre
ctre:x64-windows 3.10.0 A Compile time PCRE (almost) compatible regular ...

[liuzicheng1987]

@RampantDespair , yes, that appears to be the issue. We were using 3.8 and the moment I upgraded to 3.10, all of the regex validators failed.

[liuzicheng1987]

@RampantDespair , I figured it out. Fix will come shortly.

[liuzicheng1987]

@RampantDespair , here's the fix: dad40d3

If you're interested: The issue was that we have a trailing '\0' in our compile time strings. CTRE used to be OK with that, but but as of v3.10.0, it no longer is. Luckily, there's an easy fix.

I will make sure the tests run through, merge the PR, then close this issue.

Thanks for reporting!

[RampantDespair]

@liuzicheng1987
Wow.
Really fast fix, thank you for being so prompt! :)
I will wait for the vcpkg bundle update.

[liuzicheng1987]

@RampantDespair , I will update the vcpkg port in 2-3 weeks, there are a couple of things I want to do first.

As a quick fix, just downgrade CTRE to 3.8.