fix(navigation): use eventIndex for cross-view event targeting#788
Open
lukecotter wants to merge 6 commits into
Open
fix(navigation): use eventIndex for cross-view event targeting#788lukecotter wants to merge 6 commits into
lukecotter wants to merge 6 commits into
Conversation
- assign a monotonic eventIndex to each parsed log event and expose eventsById for stable lookups when timestamps collide - route eventIndex through call tree, timeline, soql, call stack, and problem actions so navigation resolves the exact event instead of first matching timestamp - rework call-tree row targeting to materialize the event path by id and await custom goToRow scrolling to avoid selecting adjacent rows - make row centering wait on tabulator render lifecycle and add duplicate-timestamp regressions for EventSearch and Database stack resolution
…t targeting Migrate call-tree navigation, timeline markers, row identification, and event lookups from timestamp-based to unique eventIndex throughout all cross-component flows. - Parser issues and timeline markers now carry optional eventIndex for concrete events - Call-tree navigation requires eventIndex; timestamp fallback removed entirely - Standardize all Tabulator row ids to numeric (time-order uses eventIndex; aggregated/SOQL/DML use synthetic counters) - EventBus, notifications, and UI navigation wired to propagate eventIndex end-to-end - Timeline click-to-calltree jumps now use eventIndex instead of timestamp-only lookups
only for raw-log entry
Timestamps aren't unique, so cell→detail and cross-view navigation
occasionally resolved the wrong event; the panel-already-open raw-log
entry also silently dropped its postMessage.
- CallStack/DML/SOQL/SOQLLinterIssues/DatabaseSOQLDetailPanel: stack
lookups and detail panels now key on eventIndex; drop the timestamp props,
the data-timestamp attribute, and DatabaseAccess.getStack
- EventBus timeline:navigate-to becomes a discriminated union ({
eventIndex } | { timestamp }); ApexLogTimeline listener picks the path
structurally instead of via the apexLog readiness flag, and
navigateToTimestamp now guards against unset events
- LogViewer postMessage handler accepts timestamp-only payloads (raw-log
entry) and forwards them via the timestamp branch, fixing show-in-timeline
when the panel is already open
- goToRow and the calltree timeline:navigate-to emit drop the now-dead
timestamp parameter across Timeline, ApexLogTimeline, and CalltreeView
call sites
- narrow filter-cache and DeepFilterable id types from `number | string` to `number` now that all row ids are numeric, removing an unreachable union arm - drop write-only `timestamp` fields from DMLRow/GridSOQLData rows left over after detail panels switched to eventIndex - remove the unused `idMode` branch in _navigateToSearchResult; EventNode id is always built from eventIndex (selection matches by reference, not id)
Make event-index navigation O(depth) and tolerate missing ancestors. - rewrite getStackByEventIndex to walk parent pointers from eventsById, replacing the O(n) full-tree scan with an O(depth) ascent - add _waitForTableRender so tree-expand navigation waits on renderComplete (two-frame fallback) instead of a single rAF that races the virtual renderer - fall back to the nearest resolved ancestor when an event is filtered out, rather than aborting navigation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Timestamps are not unique within an Apex log, so cross-view navigation (call tree ↔ timeline ↔ DML/SOQL detail) occasionally resolved the wrong event when two log lines shared a timestamp. This PR plumbs a monotonic
eventIndexend-to-end and reservestimestampfor the one path where it's the only key available (raw-log file → timeline entry).Changes
eventIndexto every log event and exposeseventsByIdfor O(1) lookup;EventSearchgainsfindEventByEventIndexalongsidefindEventByTimestamp.eventIndex; the timestamp props,data-timestampattribute, andDatabaseAccess.getStackare removed.eventIndex, aggregated/SOQL/DML use synthetic counters;goToRowmaterializes the path by id and awaits scroll completion to avoid selecting adjacent rows.EventBus.timeline:navigate-tobecomes a discriminated union ({ eventIndex } | { timestamp });ApexLogTimelinepicks the path structurally rather than gating onapexLogreadiness, andnavigateToTimestampnow guards against unset events.LogViewerpostMessage handler accepts the timestamp-only payload from the raw-log entry command and forwards it on the timestamp branch — fixes show-in-timeline silently dropping the message when the panel was already open.Test plan
pnpm lintpnpm test— new regressions inEventSearch.test.tsandDatabase.test.tscover duplicate-timestamp lookupsReviewer guidance
apex-log-parser/src/ApexLogParser.ts(eventIndex assignment) andcore/utility/EventSearch.ts(new lookup), then the EventBus discriminated union — the rest is propagation.tabulator/module/RowNavigation.tschanges (await scroll, path materialization) are the trickiest part of the call-tree side.