rpk: core's uint64 max value isn't correctly handled

[daisukebe]

Version & Environment

Redpanda version: (use rpk version): dev (89731b2)

What went wrong?

In Redpanda core, max_concurrent_producer_ids is set to uint64 max 18446744073709551615 by default. Here's a snip from a startup log.

INFO  2024-02-27 14:41:56,186 [shard 0:main] main - application.cc:760 - redpanda.max_concurrent_producer_ids:18446744073709551615- Max number of the active sessions (producers). When the threshold is passed Redpanda terminates old sessions. When an idle producer corresponding to the terminated session wakes up and produces - it leads to its batches being rejected with out of order sequence error.

However, rpk cluster config get max_concurrent_producer_ids returns -9223372036854775808 as this conversion doesn't work correctly.

				// currentConfig is the result of json.Unmarshal into a
				// map[string]interface{}. Due to json rules, all numbers
				// are float64. We do not want to print floats, especially
				// for large numbers.
				if f64, ok := val.(float64); ok {
					val = int64(f64)
				}

What should have happened instead?

The command should return 18446744073709551615

How to reproduce the issue?

1. Start a new cluster
2. Run rpk cluster config get max_concurrent_producer_ids

JIRA Link: CORE-1812

JIRA Link: CORE-8989

[daisukebe]

I see converting from float64 to uint64 doesn't work in a reliable way in Go. So, converting to string is the way to go as export.go does?

			case float64:
				scalarVal = strconv.FormatFloat(x, 'f', -1, 64)

[github-actions]

This issue hasn't seen activity in 3 months. If you want to keep it open, post a comment or remove the stale label – otherwise this will be closed in two weeks.

[github-actions]

This issue was closed due to lack of activity. Feel free to reopen if it's still relevant.

[r-vasquez]

Hi @daisukebe, I'm taking a look into this, and we are currently losing precision with the current way of handling it in export, if you do rpk cluster config export --all and then grep for the value, you'll see 18446744073709552000 instead of 18446744073709551615.

The cleaner solution will be to use json.Number instead, this will require a change in https://github.com/redpanda-data/common-go/blob/main/rpadmin/api_config.go#L50 and some other parts of the rpk code. I'll be working on this

[daisukebe]

Thank you, Rogger!