Feifan Zhou found this while operating RivetKit 2.3.15 with native SQLite profiling enabled.
Problem
Fingerprint admission and the other fallback use the same shared Prometheus series budget. If the budget can reserve the base tuple but cannot reserve a statement or transaction tuple, RivetKit increments rivetkit_sqlite_fingerprint_overflow_total{reason="series_budget"}, retries with other, and then drops the full profile when that reservation also fails. The operation/outcome counters are part of the fingerprint tuple, so exact aggregate counts are unavailable precisely when fingerprint attribution is exhausted.
A minimal example is a process with a 1,000-series budget. One actor/transport base tuple reserves 891 series. A statement tuple requires 147 more series, so neither the selected fingerprint nor its other fallback can be admitted. Overflow reports the attribution loss, but aggregate operation/outcome counts are also lost.
Request
Please either:
- pre-reserve
other aggregation tuples for the expected operation type, fingerprint source, transaction mode, and storage transport combinations; or
- provide fingerprint-free aggregate operation/outcome counters that do not depend on fingerprint tuple admission.
Acceptance criteria
- Exact aggregate operation/outcome counts remain available when fingerprint admission fails.
fingerprint_overflow_total continues to report attribution loss.
- Tests cover the case where the selected fingerprint reservation and the current fallback reservation both fail.
Feifan Zhou found this while operating RivetKit 2.3.15 with native SQLite profiling enabled.
Problem
Fingerprint admission and the
otherfallback use the same shared Prometheus series budget. If the budget can reserve the base tuple but cannot reserve a statement or transaction tuple, RivetKit incrementsrivetkit_sqlite_fingerprint_overflow_total{reason="series_budget"}, retries withother, and then drops the full profile when that reservation also fails. The operation/outcome counters are part of the fingerprint tuple, so exact aggregate counts are unavailable precisely when fingerprint attribution is exhausted.A minimal example is a process with a 1,000-series budget. One actor/transport base tuple reserves 891 series. A statement tuple requires 147 more series, so neither the selected fingerprint nor its
otherfallback can be admitted. Overflow reports the attribution loss, but aggregate operation/outcome counts are also lost.Request
Please either:
otheraggregation tuples for the expected operation type, fingerprint source, transaction mode, and storage transport combinations; orAcceptance criteria
fingerprint_overflow_totalcontinues to report attribution loss.