nats .conf Parser fails parsing strings

[NyanProgrammer]

Observed behavior

I used nats-kafka bridge, but I have a password that looks like this:

• dummyPass: 5e7bcd-abc10

This was an environment variable, $PASSWORD in the .conf file, while parsing I got:
'Expected a top-level value to end with a new line, comment or EOF, but got '7' instead.'

Expected behavior

Successfully parse variable from Env.

Server and client version

Server and Client v2.10.5 and current main

Host environment

nats://localhost:4222

Steps to reproduce

Add this test into conf/parse_test.go

func TestParseStringThatLooksLikeHex(t *testing.T) {
	if vmap, err := Parse(fmt.Sprintf("%s=%s", "pk", "5e7bcd-abc10")); err != nil {
		t.Fatalf("This is a valid sring but I got err: %s", err.Error())
	} else {
		fmt.Print(vmap)
	}
}

source based from: https://github.com/nats-io/nats-server/blob/v2.10.11/conf/parse.go#L402

[afan0918]

I suspect an issue originates from lines 207 to 214 in parse.go, within the func (p *parser) processItem(it item, fp string) error block:

setValue := func(it item, v interface{}) {
    if p.pedantic {
        p.setValue(&token{it, v, false, fp})
    } else {
        p.setValue(v)
    }
}

During parsing, this segment calls the function defined in lines 1151 to 1153 of lex.go:

func isNumberSuffix(r rune) bool {
    return r == 'k' || r == 'K' || r == 'm' || r == 'M' || r == 'g' || r == 'G' || r == 't' || r == 'T' || r == 'p' || r == 'P' || r == 'e' || r == 'E'
}

This may lead to misinterpretation issues. I hope this observation proves helpful for the project's maintenance.

[derekcollison]

Have you tried putting double quotes around the value to force the parser to treat as a string?

[afan0918]

Here's the new test case:

func TestParseStringThatLooksLikeHex(t *testing.T) {
    if vmap, err := Parse(fmt.Sprintf("%s=%s", "pk", "\"5c7bcd-abc10\"")); err != nil {
        t.Fatalf("Expected a valid string but received an error: %s", err.Error())
    } else {
        fmt.Print(vmap)
    }
}

With this modification, the test case should pass. Perhaps the original poster can try this solution.

[NyanProgrammer]

@derekcollison yes, I added double quotes, and It works!!