Investigate go-kong 0.61.0 and gdr 1.17.0 breaking changes

[pmalek]

Problem statement

During the release of KIC 3.4 and Gateway 3.9 we've discovered that enterprise-postgres integration test suite fails when running KIC's validate Gateway image pipeline for kong/kong-gateway-dev:3.9.0.0-rc.5

Example: https://github.com/Kong/kubernetes-ingress-controller/actions/runs/12277898800/job/34258373712

This has been discussed in https://kongstrong.slack.com/archives/C011RQPHDC7/p1733915076647379.

Probable cause

Most likely this is related to bumping go-kong to 0.61.0

Possibly related code in KIC:

• kubernetes-ingress-controller/internal/dataplane/sendconfig/dbmode.go

  Lines 194 to 198 in 4a8cbc5

  	tagsValue := reflected.FieldByName("Tags")
  	if !tagsValue.IsValid() || tagsValue.IsZero() || tagsValue.IsNil() {
  	return ResourceError{}, fmt.Errorf("entity %s/%s of type %s lacks 'Tags' field",
  	event.Entity.Kind, event.Entity.Name, reflect.TypeOf(subj))
  	}

Logs observed running locally:

2024-12-12T11:44:41+01:00	debug	events	failed to apply Kong configuration to https://10.244.0.99:8444: 2 errors occurred:
	while processing event: Create consumer-group-consumer c2 failed: HTTP status 409 (message: "Consumer '6028905a-310f-5dc7-a1c0-c741e8ad3bae' already in group 'e723d40d-03a0-558e-9b17-fbc82ff50127'")
	while processing event: Create consumer-group-consumer cnew failed: HTTP status 409 (message: "Consumer 'c7dc7349-e049-585c-b537-a0060df634c7' already in group 'e723d40d-03a0-558e-9b17-fbc82ff50127'")

Acceptance criteria

• KIC passes integration tests suite with go-kong newer than go-kong 0.60.0 running against Gateway 3.9 (RCs included) or newer
• remove version pin from go.mod

[randmonkey]

@pmalek I think the most possible breakage happens on the entity consumer_group_consumer.
From the log we can see KIC wants to create the consumer_group_consumer that has been created.

while processing event: Create consumer-group-consumer cnew failed: HTTP status 409 (message: "Consumer 'c7dc7349-e049-585c-b537-a0060df634c7' already in group 'e723d40d-03a0-558e-9b17-fbc82ff50127'")

I think it is likely that consumer_group_consumers was not listed with our config of resolving diffs in GDR so they are created again.

[pmalek]

@randmonkey You might be right. I don't know too much about this piece of code unfortunately.

Adding to v3.5.x so that this doesn't get lost in backlog.

[pmalek]

For whoever picks this up: let's make sure to add a test for this to catch possible future errors earlier rather than later. Ideally this would be covered by a UT, kongintegration or envtest test.