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

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

Ouverte
#36 2 commentaires 0 réactions 0 personnes assignées Voir sur GitHub
enhancement
Langage dominant
TypeScript
Étoiles
2
Forks
0
Merge moyen
5 h 51 min
PR mergées (30 j)
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._

Guide de contribution

Ouvrir le guide de contribution

Évaluation

Cette issue n'a pas encore été évaluée.

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.