Skip to content

Trouble Shooting

Integrate qodo AI Code Review in Github Action

Background

Background: I wrote notes and blogs regularly to record my thoughts and experiences. However, I found due to my carelles I wrote some typos, either Chinese or English, and I was aware this when I read them later. This is a painpoint for me so I would like to find a workflow to tackle it.

I first try to find a specialized spell check for both Chinese and English but failed, as a result, I try to integrate AI code review by qodo-ai/pr-agent in my github action.

Get Correct Module Name via Trie-Style Structure

Go language supports to put modules under a VCS, such as github. Usually, one git repo contains one go module and multiple packages under this module. However, this is not always correct because Go allows you to put multiple modules under the same project, and Go helps to find these modules via its path. A typical example is repository go.opentelemetry.io/otel, which contains huge amount of modules.

In my real senario, given a list of used modules parsing from go.mod, and a package name retrieving from import declaration, I want to know which module does this package belong to. strings.Contain isn't help at all because module paths have overlapped a lot.

Troubleshooting: Different Valid Tracing ID are Mingled Together

Last week, users have reported a weird issue because they found:

  • Server has received 10+ same requests to the same API in a single trace, and it's impossible.
  • Server made another RPC call when serving, the egress logging interceptor reports 2 different tracing ID. The first one is set to the context logger after parsing the trace id from client, and the second one is retrieved from the context. They should be the same.
  • The data put inside the context(will be propagated by underlying SDK when RPC) cannot be propagated to the server.

This issue is complicated due to the involved components and the cross services. It takes me a lot of time to troubleshoot and finally I found the root cause successfully. The issue happened because user used gin.Context as context.Context directly inside a spawned go routine, however, gin tries to reuse the gin.Context for another request. As a result, the go routine spawned by previous request will be affected by the new request, and the request id mingles.

gotypesalias=1 does not seem to get used correctly for deps on Go 1.23

Recently, I have help to troubleshooting the Go type alias issue inside packages.Load, which relates x/tools, go list and cmd/compile. My original CL is correct, but I got confused when I found the exportdata contains all aliases regardless gotypealias setting. Then, tim has shepherded my CL by another CL to fix it.

Feel a bit frustrated when I saw the email when I got up. But it helps me a lot to learn how go toolchain and cmd/compile works. Think twice before you act!