apex-dev-tools / apex-dev-tools/apex-log-parser

✨ feat: Refine entryPoint for logs with more than one execution

未關閉
#36 2 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
enhancement
主要語言
TypeScript
星號
2
分支
0
平均合併
5 小時 51 分鐘
30 天內合併 PR
32

描述

### Problem

`entryPoint` takes the first `CODE_UNIT_STARTED`, which is right for the large majority. It is wrong
for logs that hold more than one execution where the first one is a platform shim.

Measured over a corpus of ~124 real logs: 13 logs have more than one top-level code unit. In 11 of
them the shape is identical — two `EXECUTION_STARTED` frames, the first holding a short
`FutureHandler - state load` (about 15 ms), the second holding the real work. In the worst case the
first code unit is 15 ms and the second runs 98 s, so "first" names a shim and hides the transaction
the reader opened the log for.

Example: `apex-07LJ0000012MdHFMA2.log` —
`FutureHandler - state load` 15 ms, then `LC_Package_Setup...` 98 s.

### Proposed solution

Options to weigh:

- Keep `entryPoint` as first, and add an explicit list of executions so a consumer can pick.
- Choose the code unit of the longest, or the last, execution.
- Expose both: the first code unit and the dominant one.

Whatever is chosen, do not silently reorder — a caller must be able to tell which rule produced the
answer.

#### Acceptance

- The 11 `FutureHandler - state load` logs name the real operation, not the shim.
- The rule is documented, and a single-execution log is unaffected.

### Alternatives considered

_None recorded._

貢獻指南

開啟貢獻指南

評估

這個 Issue 還沒有評估資料。

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。