server, sql: surface session txnCount, txn fingerprints, active time

[cockroach-teamcity]

Exalate commented:

Related PR: cockroachdb/cockroach#82352
Commit: cockroachdb/cockroach@ceb5981

---

Release note (api change): the serverpb.Session struct now has three
new fields: number of transactions executed, transaction fingerprint
IDs, and total active time.

Jira Issue: DOC-4645

[exalate-issue-sync]

Mike Lewis (mikeCRL) commented:
Stephanie Bodoff Andrew Feierabend Ryan Kuo I’m adding the SQL Observability area here, per what I’m seeing in the underlying issue, but given the additional HTTP API group on the PR, I’m wondering if this needs to be reflected in the Cluster API docs. I am not sure if those docs now fall under Observability Infrastructure. I thought they did, but the Product Areas list mentions non-Cloud APIs under Deployment and Operations only.

Can anyone please help research or clarify the scope of the PR and doc/product area impacts?

[exalate-issue-sync]

Stephanie Bodoff (stbof) commented:
Mike Lewis We don’t document these management API endpoints.

[exalate-issue-sync]

Ian Evans (ianjevans) commented:
Stephanie Bodoff is correct. That endpoint ({{/_status/sessions}}) is not intended to be used by the public, but many eng PRs add release note strings for any API change. So I’m +1 on closing with Won’t Do.

[exalate-issue-sync]

Mike Lewis (mikeCRL) commented:
When we first created the Cluster API docs, I don’t remember excluding any functionality, so now I’m wondering where this change fits in with what we already have here under {{/sessions}}.

If this is the same resource as the one that’s affected per this issue, we should consider removing it from the docs or keeping it updated, with a caveat about internal use. (If it’s used internally, perhaps engineers would still like to have it properly documented). What we should avoid at the very least, though, is a case where it’s not up to date and also there’s also no warning about internal use.

The other question is whether to exclude this from release notes. Our standard says to provide release notes for any change to a public API; but is this a public API with a non-public endpoint/resource? Perhaps the decision on what to do in this case would flow from what we decide to document regarding the resource.

Again, all this assumes we’re talking about the same resource. Does anyone know for sure?