Fix error messages to dereference pointer values and explicitly show NULL

[Copilot]

Error messages were printing pointer addresses like pk0=(*float64)(0xc00b7ba650) instead of actual values, making it impossible to correlate failures with statement logs.

Changes

• Refactored formatRows to handle pointer dereferencing via type switch

  • Explicit cases for all pointer types: numeric (int8-64, uint8-64, float32-64), string, bool, time.Time, time.Duration, UUID, []byte, *big.Int, *inf.Dec
  • Nil checks before dereferencing
  • Writes "null" explicitly for nil values (both untyped nil and typed nil pointers) for clear indication
  • Changed default format verb from %#v to %v
  • Removed reflection dependency

• Added test coverage for pointer value formatting

Example

Before:

row count differ (missing_in_oracle=[pk0=(*float64)(0xc00b7ba650),ck1=(*string)(0xc036611dd0)])

After:

row count differ (missing_in_oracle=[pk0=3.14159,ck1=test_value])

For null values:

row count differ (missing_in_oracle=[pk0=null,pk1=null])

[!WARNING]

Original prompt

---

This section details on the original issue you should resolve

<filter_complete></filter_complete>

<issue_title>Error message does not show column values properly</issue_title>
<issue_description>In error message we can see:

Deleted partition validation failed (difference found): row count differ (missing_in_test=[], missing_in_oracle=[pk0=(*float64)(0xc00b7ba650),pk1=&gocql.UUID{0x3b, 0xcc, 0xff, 0xf6, 0xb3, 0x59, 0x4b, 0x3a, 0xa0, 0x16, 0xe3, 0x4a, 0x53, 0x8a, 0x36, 0x66},ck0=(*time.Duration)(0xc00b7ba658),ck1=(*string)(0xc036611dd0)])

which is not showing values which can't be matched to statements log.

https://argus.scylladb.com/tests/scylla-cluster-tests/de5fd192-0c22-4199-96d5-f66a29401d2c/events

gemini 2.2.2</issue_description>

Comments on the Issue (you are @copilot in this section)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Error message does not show column values properly</issue_title>
<issue_description>In error message we can see:

Deleted partition validation failed (difference found): row count differ (missing_in_test=[], missing_in_oracle=[pk0=(*float64)(0xc00b7ba650),pk1=&gocql.UUID{0x3b, 0xcc, 0xff, 0xf6, 0xb3, 0x59, 0x4b, 0x3a, 0xa0, 0x16, 0xe3, 0x4a, 0x53, 0x8a, 0x36, 0x66},ck0=(*time.Duration)(0xc00b7ba658),ck1=(*string)(0xc036611dd0)])

which is not showing values which can't be matched to statements log.

https://argus.scylladb.com/tests/scylla-cluster-tests/de5fd192-0c22-4199-96d5-f66a29401d2c/events

gemini 2.2.2</issue_description>

Comments on the Issue (you are @copilot in this section)

• Fixes Error message does not show column values properly #596

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[CodeLieutenant]

@copilot look like we have double check for nil, if value == nil, and later then in each switch case, do we need that?

[Copilot]

@copilot look like we have double check for nil, if value == nil, and later then in each switch case, do we need that?

Both checks are needed because they handle different nil cases:

1. if value == nil (line 36) - catches untyped nil (the nil literal). Without this, untyped nil would fall through to the default case and print <nil>.

2. if v != nil in each case - catches typed nil pointers (e.g., var x *string where x == nil). These don't match value == nil because the interface holds a typed pointer, even though it's nil.

Example:

• formatRows(sb, "key", nil) → caught by line 36, returns "key="
• var x *string; formatRows(sb, "key", x) → passes line 36, matches case *string, caught by if v != nil, returns "key="

Both produce the same output (empty value) but handle different nil scenarios. We could remove the first check, but then untyped nil would print "key=<nil>" via the default case instead of "key=".

[CodeLieutenant]

Copilot it really bad at writing commit messages, I'll amend these commits

[mykaul]

Copilot it really bad at writing commit messages, I'll amend these commits

Yes, but we never gave it any instructions on what we expect in a good commit message.