Add Runtime and Console transport core#132
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4281f29cbb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fbe78bdfbf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| selectedNodeStyleHydrationTask?.cancel() | ||
| selectedNodeStyleHydrationTask = nil | ||
| selectedNodeStyleHydrationIdentity = nil |
There was a problem hiding this comment.
Reset selected style refresh state when cancelling hydration
Cancelling selectedNodeStyleHydrationTask here leaves the selected node in .loading when cancellation happens mid-refresh (for example, switching away from the Elements view while style requests are in flight). refreshStyles(for:) explicitly skips markRefreshFailed on CancellationError, and selectedNodeStyleHydrationState() treats .loading as .refreshing, so when the view becomes active again no new refresh is scheduled and the UI can remain stuck in a perpetual loading state for that node.
Useful? React with 👍 / 👎.
| if let defaultContextKey = targetState.normalContextKey { | ||
| if oldContextKeys.contains(defaultContextKey) { | ||
| targetState.normalContextKey = record.key | ||
| } | ||
| } else { | ||
| targetState.normalContextKey = record.key | ||
| } |
There was a problem hiding this comment.
Promote main-world context when later normal context arrives
The default context for a target is only set once unless the previous default is explicitly replaced, so if a subframe normal context is seen before the page’s main-world context, normalContextKey stays pinned to the subframe. RuntimeSession.evaluateIntent prefers selected/default context, so subsequent evaluations for that page target can run in the wrong frame context instead of the main world whenever event ordering delivers subframe context creation first.
Useful? React with 👍 / 👎.
| for record in snapshot.executionContextsByKey.values.sorted(by: { $0.id.rawValue < $1.id.rawValue }) { | ||
| runtime.applyExecutionContextCreated(record) |
There was a problem hiding this comment.
Use deterministic key when seeding runtime contexts
executionContextId is now only unique within a runtime-agent target, but this seed pass sorts solely by id. When two contexts share the same id across different runtime agents, their relative order depends on dictionary iteration, which is explicitly unpredictable; whichever one is applied first can become the target’s default/selected normal context. That makes initial evaluation routing nondeterministic after reconnect/bootstrap for pages with colliding context IDs.
Useful? React with 👍 / 👎.
Summary
Testing
Screenshots
Related