Open Source
Recurring problems, not one-off patches.
Across every codebase I've contributed to - OpenTelemetry, Prometheus, Liquibase, Apicurio, GoFr - the bugs I gravitate toward cluster into a handful of patterns: silent failures, thread-safety gaps, unbounded cardinality, spec drift. Browse by problem category below, not by repo.
Observability Cardinality Control
Telemetry systems fail differently: not a crash, but an attribute or limit that quietly lets a metric or log label grow unbounded until it becomes a cost or performance problem for whoever's running it.
OpenTelemetry C++ SDKConfigurable per-instrument-type cardinality limits for the Metrics SDK
The Metrics SDK hardcoded a 2000 cardinality limit and silently discarded any user-supplied override from declarative YAML config.
Wired a configurable limit through MetricReader and CollectorHandle end-to-end, fixing a sentinel-value bug along the way; a follow-up fix (#4314) closed a gap where histogram views setting only a cardinality limit were silently rejected.
OpenTelemetry Go Contrib (otelmongo)Unbounded network.peer.address cardinality from pooled connection IDs
Pooled connection ID suffixes from the Mongo driver broke host/port parsing, so the fallback path used the whole per-connection string as the hostname - unique per connection instead of stable per host.
Stripped the suffix before parsing and ported the identical fix to the older v1 instrumentation package.
OpenTelemetry Go (Compile Instrumentation)Missing runtime disable gate for a cardinality-risk attribute
gin's instrumentation set http.route unconditionally, a real cardinality risk on large routers, and OTEL_GO_DISABLED_INSTRUMENTATIONS=gin had no effect since it never checked the runtime gate every other package used.
Gave gin its own instrumentation key and hardened the enable/disable check against the env var changing mid-request.
