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

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

Open
#36 2 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
TypeScript
Stars
2
Forks
0
Avg merge
5h 51m
Merged PRs (30d)
32

Description

### 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._

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.