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

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

Abierto
#36 2 comentarios 0 reacciones 0 asignados Ver en GitHub
enhancement
Lenguaje dominante
TypeScript
Estrellas
2
Forks
0
Merge medio
5 h 51 min
PR fusionados (30 d)
32

Descripción

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

Guía de contribución

Abrir la guía de contribución

Evaluación

Este issue todavía no se ha evaluado.

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.