Review per-request debug logging in internal/ct/handlers.go

Open
#843 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go
Domain
backend, observability

Research direction

Start by reading internal/ct/handlers.go, especially appHandler.ServeHTTP and addChainInternal, and trace the existing tracer.Start spans around those request paths. Review each per-request slog.Debug call and decide whether it should be removed, represented as an OpenTelemetry span event or attribute, or retained with a justification. Done means every relevant call has an explicit decision and the resulting logging is no longer unnecessarily chatty.

Written by the indexing model from the issue text.

Description

Spun out of review feedback on #841 (klog → slog migration).

The per-request slog.Debug calls in internal/ct/handlers.go (e.g. the request-received line at the top of appHandler.ServeHTTP, the => storage.Add and <= SCT markers in addChainInternal, etc.) will be extremely chatty for a public-facing log if debug is ever enabled.

The migration preserved them as direct equivalents of the old klog.V(N).Infof calls, but it's worth asking whether they're still the right tool:

  • A lot of this is essentially "what happened during this request?" data, which OpenTelemetry spans/events would represent more cleanly (already wired up via tracer.Start).
  • Some calls may simply be obsolete and safe to delete.

Action: audit the per-request debug logs and either drop them, fold them into the existing OTel span as events/attributes, or keep them with a justification.

Related: #842 (the same reasoning applies to requestlog.go).

Dominant language
Go
Stars
37
Forks
18
Avg merge
19h 22m
Merged PRs (30d)
15

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from transparency-dev/tesseract

All issues in transparency-dev/tesseract

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.