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 摘要。