Say that lineNumber is the call site in the caller's file

[lukecotter]

Every apexlog_list_slow_operations row carries lineNumber, and nothing says what it is a line of. It is the call site in the caller's file — never a line in the callee.

Verified against the extension repo's sample-app. lineNumber is parseLineNumber(parts[2]) — the [42] bracket on the log line:

log line	AccountService.cls
METHOD_ENTRY|[11]|AccountService.getRevenue()	11: Decimal revenue = getRevenue();
DML_BEGIN|[36]|Op:Insert|Type:Account	36: insert accountsToInsert;
SYSTEM_METHOD_ENTRY|[19]|List<Account>.add(Object)	19: accountsToInsert.add(acc);

An agent that reads it as the callee's line opens the wrong file.

Change

The SlowOperation.lineNumber doc comment and the tool description. No response change and no new column.

Measured

60 real logs, the default grouped top ten, 583 rows:

kind	rows	null	EXTERNAL
method	270	0	28
codeUnit	90	90	0
soql	81	0	0
systemMethod	66	50	0
flow	37	37	0
dml	27	0	0
workflow	7	7	0
managedPackage	5	5	0

Null on 32.4%, but structurally so: codeUnit, flow, workflow and managedPackage have no Apex call site. Every kind that has one reports it.

Blocks 2.0.0.

[lukecotter]

Closing as not planned: lineNumber is dropped from apexlog_list_slow_operations instead of documented.

Saying what it points at cost 21 tokens in the tool definition, charged on every turn whether the tool is called or not, and the column itself ~18 tokens per governor-heavy response. Against that: measured over 60 real logs, the default grouped top ten, 583 rows, it is null on 32.4% of them — codeUnit, flow, workflow and managedPackage have no Apex call site at all — and on the 7% of grouped rows that fold calls from more than one caller it names only the slowest call.

Nothing has shipped with the column, so the 2.0.0 changelog reads as if it never existed.

Worth revisiting if a caller needs a source pointer on the rows whose name names nothing openable (DML Op:Insert Type:Account, List<Account>.add(Object)). The owning file is the nearest ancestor method or codeUnit, which Operation.parent already carries and which resolves on 99.2% of numeric rows.

Removed in #140.