open-telemetry/opentelemetry-kotlin

The spec states "The SDK MUST guarantee that the span can no longer be modified by any other thread before invoking OnEnding of the first SpanProcessor. From that point on, modifications are only allowed synchronously from within the invoked OnEnding callbacks." Currently in SpanModel endInternal calls onEnding outside the lock, and as mutate {} gates on isRecordingInternal() it's possible to mutate the span concurrently.

The spec states that each language implementation must create a language-specific document that details how versioning requirements are met: https://opentelemetry.io/docs/specs/otel/versioning-and-stability

The spec states: When mutating tracestate, the order of unmodified key/value pairs MUST be preserved. Modified keys MUST be moved to the beginning (left) of the list.* Currently TraceStateImpl appends the new key to the end of a LinkedHashMap, meaning the wire format receives the wrong order. put needs to remove any existing entry for the key and prepend the new paid, which leaves the correct order.

opentelemetry-java anchors on currentTimeMillis() once and measures elapsed time afterwards with System.nanoTime(). This would be a better approach for JVM (but not android). For Android we should see the approach taken in opentelemetry-android, which baselines on currentTimeMillis(). Nanosecond resolution is not possible on Android, so millisecond resolution is acceptable. I haven't looked into JS/Apple but it's possible improvements are available there too.

Goal Define the internal MetricStorage API required by metric instruments to record measurements and by the SDK to read them back. The API should provide the storage contracts needed for recording and collecting metric measurements without defining concrete instruments, aggregation implementations, or metric export. Scope Define readable and writable metric storage contracts. Associate storage with an instrument and its resolved stream descriptor. Support Long and Double measurements with attributes and context. Support recording timestamps and cumulative/delta collection semantics. Ensure recording is thread-safe. Provide an extensible storage boundary for future aggregation and exemplar support. Account for attribute cardinality and cardinality limits at the storage boundary where required by the SDK specification. Concrete instruments, aggregations, readers, exporters, and provider wiring are out of scope. Specification Metrics Data Model Metrics API Metrics SDK Measurement Proce