Minor: nil logger context, unhandled unsubscribe lookup error, grpc dependency for two stubs

Author: runaway518Created Sep 2, 2026Updated Sep 2, 2026

Three small things noticed while reviewing dev for a downstream fork. Grouped since none warrants its own issue.

1. nil context passed to the logger

core/internal/service/relay/config_sync.go:827, added in ecf65116:

go
g.Log().Infof(nil, "Removed relay configuration block from %s", cfPath)

Every other logging call in the file passes a real context. Confirmed not to panic in practice — the surrounding write completes — but it is inconsistent, and nil contexts are a hazard if the logger later dereferences one.

2. Unhandled error on the unsubscribe sender lookup

core/internal/controller/batch_mail/batch_mail_v1_unsubscribe_new.go, added in f0acca4c:

go
var senderEmail string
if claims.TaskId > 0 {
    val, _ := g.DB().Model("email_tasks").Where("id", claims.TaskId).Value("addresser")
    senderEmail = val.String()
}
hostUrl := domains.GetBaseURLBySender(senderEmail)

The error is discarded. The failure mode is benign — GetBaseURLBySender("") falls back to GetBaseURL() — but it degrades silently, on a public unauthenticated endpoint, so a misconfiguration is invisible.

3. google.golang.org/grpc is pulled in only for two unimplemented stubs

core/internal/controller/files/files_v1_read_file.go and files_v1_download_file.go:

go
return nil, status.Errorf(codes.Unimplemented, "Not yet achieved")

These are the only uses of gRPC in the module. go mod tidy therefore makes google.golang.org/grpc a direct requirement and adds google.golang.org/protobuf and google.golang.org/genproto/googleapis/rpc as indirects — a sizeable dependency subtree for two HTTP handlers that return a placeholder error.

Returning a plain error (or a GoFrame error) from those two stubs would drop all three modules from the dependency graph.

Note this is only visible after running go mod tidy: core/go.mod currently omits grpc even though it is imported, so go build ./... fails with go: updates to go.mod needed until tidy is run. core/go-build.sh runs tidy as a build step, which is why the container build is unaffected.