apex-dev-tools / apex-dev-tools/apex-log-parser
✨ feat: Refine entryPoint for logs with more than one execution
- 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
Assessment
This issue has not been assessed yet.